1. Other suggestions
Since we're again on the namespace issue, this is *how* and *what* I like to
see it be improved:
1) NameSpace improved:
1.1) A file can only use global identifers that are included by the
file directly, or globally included by a file that is included directly.
(globall included: "global include")
1.2) I should be able to over'load' any identifer as long as the
scope not precizely equal. (read: I should be able to over'load' any
identifer as long as its not in the same file)
1.3) A new keyword to include a file: 'own' it both includes that
file, as replace that file wherever it is included. So, if fileA does an
'include fileB.e' and fileC owns fileB, then all global identifers of fileC
would be available to fileA, rather than those of fileB. However when fileC
globally owns fileA than all global identifers fileA calls that are not
found in fileC, will be looked for in fileB. (globally own: "global own")
Yeah, yeah you need to reread this section a couple of times, before you get
it.. Maybe draw it out 
.. j/k
1.4) Bind/shroud should not contain any bugs/issues/features
(whatever you call it). You can always pull a trick with the interpreter
itself. Also a switch to exclude certain files would be great, I might want
to keep an "config.e" file apart from the bindend/shrouded file or something
like that.
2) Structured goto's:
2.1) Being able to name any block construct. Something like: "
MainGameLoop: while 1 do " or more consistent: " while 1 as MainGameLoop do"
2.2) Being able to exit a block construct using "exit
(MainGameLoop)" so we can easily, readably, jump out of multiple levels of
statement blocks. This should only work when you are *in* the statement
block. (otherwise it is undefined)
2.3) Being able to continue a block construct using "continue
(MainGameLoop)" so we can easily, readably, restart (but first re-evaluate)
the block construct we are in. This should only work when you are *in* the
statement block. (otherwise it is undefined)
3) Declarations
3.1) Fixed-length sequences rather than structures: When I declare
any data-object (a sequence, integer, atom, user-defined) like this: "atom
x[4]" it only allows 'x' to be a 4-element sequence, containing atoms. This
helps a lot with type-checking of common and simple sequences. And it speeds
things up a *lot*. Btw, this would thus also work: " sequence foo[4][5] "
meaning a 'table' of 4x5 containing sequences is the only allowed format.
3.2) We should be able to initialize a variable at the declaration
itself: " integer foo = 4 "
4) Slicing
4.1) Length of sequence don't have to be equal when assigning a
value: " x[2..3] = foo[4..8] " means it should put the 4 elements of foo
(from 4 to 8) where the 2 elements of x previously were. That x is now a
*longer* sequence is the *wanted* effect, rather than the error that we now
get.
4.2) I like the '~' suggestion, its means 'endless' and therefor is
the perfect symbol for foo[1..~] or just foo[1~]. Instead of using length "
( .. name of variable .. ) "
4.3) Reversed slicing should give the sequence in reverserd form,
rather than creating another error. foo[~..1] or at least provide a fast
internal reverse routine.
4.4) Multilevel slicing should work, as long as we dont cross any
borders: foo[][2..~] would slice *all* elements of foo, from 2 to the length
of those elements. foo[2..4][~..2] would do the same, only return them
reversed (see point 4.3)
4.5) I should be able to assing something to a constructed sequence:
" { a, b, c } & g = my_sequence " It would allow for *readable* and *fast*
assignment without the use of zillions of dummy variables.
4.6) Slicing should be recursive. If I pass a sequence as an slice
index, it should use all elements. foo[{1,2,3}] would be equal to
foo[1][2][3] and foo[{{1,2},{2,3},{3,4}] would be equal to
foo[1..2][2..3][3..4]
5) Platforms and OS-specific and other misc stuff
5.1) Im still in favor of a graphics.e file that also works for
win32 (and linux when it comes)
5.2) Be able to call .lib files under DOS32.
5.3) Have the euphoria interpreter in an DLL, so one could easily
make a wrapper-dll as an browser *plugin* for example.
5.4) Be able to bind euphoria libraries into DLL files.
5.5) Conditional 'compiler' directives. An "exclude 1 do" would
exclude the code beneath until the end exclude. Esspecially usefull in multi
platform programs. (this off course only works on the top-level)
5.6) Allow /* and */ as comment symbols, so we dont need to use '--'
half a page at certain points. (these symbols would work accros as many
lines as we want, or in the middle of a statement (but would you want that
?)
6) More constructs and operator improvements:
6.1) "For each char in line do" (david's invention would allow
for more readable and faster code. Consider this example: " for each char in
line do result = result + 1 end for " is all you need to calculate the sum
of a sequence for example. Changing char would also infect the the sequence
'line' *and* this would also be possible (look at point 4.5) " for each
x, y } is positions do "
6.2) Multiple mathimatical operators means, that it should apply on
a lower level: " x ++ {4,5} " means, every element of x is added {4,5}
rather than forcing x and {4,5} to be equal and add 4 to the first and 5 to
the second element. So a " {{{1,2,3}}} **** {2,1} " would evaluate to
{{{{2,1},{4,2},{6,3}}}}
Thats it for the moment ..
Ralf
