OpenEuphoria

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
>
>
>
>