RE: Wish list
- Posted by rforno at tutopia.com Jul 31, 2002
- 381 views
----- Original Message ----- From: Robert Craig <rds at RapidEuphoria.com> Subject: Re: Wish list > > Ricardo Forno writes: > > 1) Comments C type: /* ... */ to ease commenting out code blocks. > > I use F12 in ed to insert a bunch of comments. > (Removing them is a bit harder.) > In C, I find it strange that there are two different ways > of commenting code. /* ... */ was the original way, > then they added // to be more compatible with C++. > I can never make up my mind which one to use, so > I use both, almost at random. I'd rather stick to one > consistent method. > I was not thinking about inserting a block of comments, but only to comment out a block of code. It is a bit tiresome to insert -- before each line, and then removing this when you want the block to be in effect again. In ed, I find no way to do this. I can do it easyly with other editors, but I like the ed facilities, in spite it departs from the usual standards. By the way, ed will be a bit better if instead of inserting tabs it inserted spaces (as it does now with 4 spaces). I know it can be modified to do that, but I am somewhat lazy .Why not admit both commenting styles, especially considering that the current comment style is the only "sentence" that ends at a new line? > > 2) Enhancements to the trace facility: > > A) Variables should not be shown automatically but only at an user > > request. > > Why? What harm does it do to show a few variables on the screen > automatically? Please see my answer to Derek on this and some other subjects. > > > B) Allow showing expressions, at least of the form x[i][k], > > z[2..n], etc. > > Yes, I'll probably do that in the next release. > > > Better if all valid expressions were allowed, including > > function calls. > > True, but unfortunately it's extremely difficult to implement. > > > c) On a more advanced mood, allow entering the editor while in trace > > mode, defining and executing new routines, modifying old ones, > > modifying and creating variables, etc. > > That's hard too. > > > 3) Allow executing string variables, that can > > contain code like "x = y * p". > > 4) Allow defining functions from a string, for example: > > "function foo(integer u) return power(u, u) end function" > > I don't like any feature that requires code or variables to be constructed > at run-time and executed. I used this in APL, and found it > was an overly-powerful solution searching desperately for a problem. > Rarely useful in practice. Theoretically it buys you nothing > in terms of the algorithms you can implement. > It's also extremely hard to implement in the current interpreter > without starting from scratch. Any translated to C code that > used this feature would need to carry around a > complete copy of the interpreter. It may be, but when I worked with APL I found this feature to be very helpful in many cases, and I am not referring to scientific tasks only, but mainly to commercial ones. Anyway, I understand that it should be difficult to implement. > > > 5) A function that returns the amount of available real storage at the > > moment. > > It will ease the task of determining the size of buffers to avoid > > using virtual storage. > > You could write a routine that calls allocate() with progressively > smaller sizes until it doesn't get a 0 returned, although that > wouldn't exclude virtual storage. > > You might want to know the total free space, or you might want > to know the largest contiguous block of storage that's available. > > You'd also need to know how much space Euphoria variables > consume. I don't like to make the implementation details > of Euphoria's internal representation so explicit. > In most Euphoria programming you shouldn't have to think > in terms of bits, bytes and nibbles. > > I might consider doing something, > but now that I have 256Mb RAM, > I don't expect to run out of memory very often. > > > 6) A facility to save the status and variables > > of a program in the middle of > > execution, also available from the trace screen. This will ease > > debugging; you could advance execution to a certain point, save, > > continue, and in case of failure, restart at the saved point. > > Do you want me to undo all the changes that you've made to files? > Set the screen back the way it was? Open and close windows, > undo the side effects of .dll routines that you've called, > memory that you've overwritten, etc.? Maybe not as a first approach. Only as a debugging help with intricate programs that do not have side effects, for example. > > > 7) Add the following *internal* data types: byte, word (2 bytes), and > > perhaps (why not?) bit and nibble (half byte), all in > > order to save storage. > > Programs should switch from one to other according to needs. > > For example, assume a sequence s s = {}. Then, s &= 1. This can > > be a byte (or bit) type. If then s &= 65, it remains byte. If then > > s &= 3456, it should switch to word (the entire sequence). If then > > s[1] = 12345678, it should switch to the current Euphoria integer type. > > If then s[2] = 89.876, maybe the current scheme could be maintained > > (AFAIK, only this element becomes floating point, and the rest remain > > integer), or else the entire sequence switches to floating. > > You've just described exactly the way APL does things. > The problem with having n internal data types, is that you > have to handle n-squared cases for every binary operation > in the interpreter (or translator). This would be slow, and would > bloat the interpreter. It would also increase the number of bugs > in the interpreter with all those extra cases to test. > I know. I am not an expert C programmer, but in Assembly you could do it with not much overhead by means of a jump table, and then "promote" the lesser capacity item to the other one, if they were different, before operating on them. This is, of course, a simplification to the whole problem. Just a thought... > > 8) Rob, you know I like APL. There is a > > feature of APL that I think would be > > good to implement. +/s would compute the sum of the elements of s, > > in some way to be defined if s is not a simple sequence. > > The same for */s, file://s, /%s (where % is a new notation for > > "remainder"), etc. > > Just use a simple for-loop or a subroutine. > Why introduce a fancy new concept? > I admit +/ etc. was useful in APL, > but APL has different, very rectangular data structures. > > > 10) Add officially to Euphoria the Win32lib, > > or any replacement for it. This > > will surely increase the market share for Euphoria. > > Derek is actively working on Win32Lib, > so any bundled version would quickly become obsolete. > Win32Lib also has different copyright restrictions. > Things would get confusing. I'd like to keep my work separate, > especially since I'm charging money for it. > > Regards, > Rob Craig > Rapid Deployment Software > http://www.RapidEuphoria.com > > > >