RE: "eval()" commands/crash callbacks/ect. for Euphoria 2.5?
- Posted by CoJaBo <cojabo at suscom.net> Jan 14, 2004
- 364 views
What on earth just happened to my message!?! "=20"s everywere! Why? CoJaBo wrote: > > > I don't see why Euphoria can't support at least the first two. > > A way to recvor from errors is almost absolutly nessescery in > programs=20 > that have a lot of user data when they might crash.(like Win32Lib IDE) > > Almost all other languages I've used had an "eval()" command, this > would= > =20 > be very useful in Euphoria. > > > Kat wrote: > >=20 > >=20 > > On 13 Jan 2004, at 22:52, CoJaBo wrote: > >=20 > > >=20 > > >=20 > > > Does anyone agree? > >=20 > > I agree, see notes below........=20 > >=20=20 > > > CoJaBo wrote: > > > >=20 > > > >=20 > > > > Some of the following is missing from Euphoria and would be very > > > > helpful to me and many other programmers. I would like to see this in= > > > > > Eu 2.5. Please take these into consideration. > > > >=20 > > > >=20 > > > > "eval()" commands: > > > > I would really like to see a way to do an "eval()" type command. > > > > Many other languages have something like this. > >=20 > > RobC said no already, over and over, so Karl added it to Bach. Try it,= > =20 > > it's=20 > > plenty fast over any interpreter written in Eu in the archives. > >=20 > > > > _________________________________________________ > > > > Crash callback > > > > A way to setup a callback function would allow programs to save user= > =20 > > > > data before exiting > > > > with ex.err > >=20 > > I agree. Most do. RobC didn't. > >=20 > > > > set_crash(integer routine_id) > >=20 > > Ditto. > >=20 > > > > _________________________________________________ > > > >=20 > > > >=20 > > > > routine_id() for variables > > > > I would like to see a varible_id systym (like routine id) > > > > example: > > > > integer a,a_id a=3D3 > > > > a_id=3Dvar_id("a") > > > > ?get_var(a_id) > > > > --displays 3 > > > > set_var(a_id,4) > > > > --a now is 4 > >=20 > > Well, could be less complicated than that, but RobC said no, and Karl=20 > > has=20 > > said maybe (i think). If Eu used one byte per ascii char, this could be= > =20 > > more=20 > > useful than it would be now. It could be otherwise useful in dos32 semi- > > threaded apps if the app and var locations weren't paged out from under= > =20 > > the=20 > > known memory locations. > >=20 > > > > and mayby a way to see if a var exists/is set > >=20 > > Ditto, RobC said no. Karl may add it to Bach. It's handy in mirc. But=20 > > then,=20 > > you can build your own var names in mirc while it's running, which is=20 > > *very*=20 > > handy.=20 > >=20 > > You can use associated lists (Jiri and others have written them), or > > you= > =20 > >=20 > > could use pokes/peeks into memory (others have written those). Both=20 > > approaches are likely much slower than if implemented in core Eu. The=20 > > associated lists in Eu are faster than in mirc, especially if you wanna= > =20 > > wildmatch var names, such as: > >=20 > > 1) this.is.a.var.name > > 2) this.is.also.a.var.name <snip>