Ideas for Euphoria v2.5
Hello there,
Now that i've seen the call for "Major ideas" for 2.5, i have to say
that a really major improvement would be to have a Windows based
debugger for operations on Windows systems.
I considered building one myself a while back.
Also, a secondary thread too, if that's possible.
If this is *too* major, than how about these:
[1]
Allow an include file to be included more than once, with
a different namespace qualifier.
The reasoning for it would be to reuse all the functions (global and
local) and all the variables too, while allowing individual globals
to be overwritten by new ones with the same name, while all the
local variables are simply taken out a second time as a second
(or Nth) instance with the same name. The local constants would
be simply reused unless they were initialized with a variable statement.
In short, the second (or nth) include of the same file (within the
current file) with a different namespace qualifier would make it act
the same way as an exact copy of the file with a different filename.
The only difference would be if there were also global overrides
possible,
but that's another story anyway and not as important.
Example:
-------------------------------------
--start of File.ew:
atom x,y,z
x=0 y=0 z=0
global procedure Load_x(atom a)
x=a
end procedure
global function Get_x_y_z()
return {x,y,x}
end function
--end of File.ew
-------------------------------------
include File.ew as X1
include File.ew as X2
include File.ew as Xn
X1:Load_x(1) --now File_X1's x=1
X2:Load_x(2) --now File_X2's x=2 but File_X1's x is still x=1
Xn:Load_x(n) --etc.
The implementation should be very straightforward, for example:
1. Load the file once into memory calling it by it's real name, then
2. Make a clone with some other name that cant be found in a file
system.
Of course it would be faster to parse it once and make all the clones
with
the resulting object, perhaps locating them in a different 'system'
namespace
invisible to the user. Just some ideas though.
Should be very easy to implement i would think because it doesnt involve
anything new really.
While this is all going on, the file would retain the ability to
be able to include itself with a namespace as it does now.
[2a]
reallocate()
This would be separate from 'allocate()' instead of making 'allocate'
act like 'reallocate' for already used variables, because keeping
track of 'reallocate' is different than keeping track of
allocate/free pairs.
Also easy to implement.
[2b]
If there was some way to force the pointer to zero (0) after it
got free'd, that would really be nice. In certain cases it
would be good to be able to test a pointer to see if it had
already been free'd. If it takes up too much time relative to the
other housekeeping that has to go on with the free'ing then
i'd retract my request without hesitation. I guess a good
threshold would be about 10% or less, with 20% as a max.
[3]
I find that the current memory exception handling is good.
[4]
I have to second the nomination for adding a fault handler
in case something goes Eu wrong during execution that wasnt
expected...and one level should be adequate...if the
fatal error code cant handle the problem then go to
the default error handler as is in place now.
This gives the end user the chance to recover data,
but not to keep on running the application.
Example:
Text Editor!
A built from-the-ground-up text editor, after running for
months on countless files, suddenly and very unexpectedly
crashes. A nice way to handle this case, especially if
the text is stored in sequences of sequences (where each line
or object is a separate sequence) would be to open a
"Fatal Save As" dialog box allowing the user to select a
path, then to index through the buffer sequence testing
each sub sequence for length and saving each object to
disk. Since there would be only two mechanisms
(dialog box, indexing and writing) i would think
this could be very error proofed beforehand.
Heck, with a little tact the file could be reloaded
again and scrolled and the cursor placed back in the
last valid position 
I'd bet that when text editors crash 99.999 percent of
their data is recoverable.
onSequenceInvalidIndex(routine_id("handle_it")) comes to mind
as someone else was talking about.
I think that would cover about 101% of all Eu errors
Take care for now,
Al
|
Not Categorized, Please Help
|
|
