OpenEuphoria

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>