Re: Thoughts on eval()
- Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Dec 14, 2004
- 554 views
Jason Gade wrote: > > Hey, Matt. > > Have you read my previous idea? <a > href="http://www.listfilter.com/EUforum/m8646.html">http://www.listfilter.com/EUforum/m8646.html</a> > > I think if you have func(args, text) or proc(args, text) be functions that > return a > routine_id(). The functions themselves, as you say, insert their text into > the normal > Code[] space after being scanned and parsed. Then you just call your eval'ed > function > with call_func(id, {}) or whatever. > > I think it would require a bit of re-wiring. My original proposal was to > overload > function and procedure like integer, atom, object, and sequence are. Looking > further > into keylist.e, though, I think it would be much easier to just add func() and > proc(). > It would still be consistent with call_func() and call_proc(). No, I think it's easier to simply treat what's passed to eval() as more code for euphoria to parse and execute. > > example: > }}} <eucode> > > integer a, b, c, rid > sequence args, text > > args = "integer x, integer y" > text = "return x + y" > > rid = func(args, text) > > a = 2 > b = 2 > > c = call_func(rid, {a, b}) -- c is now 4 > > </eucode> {{{ > > Problem would be what happens when rid no longer refers to the function? How > is it > destroyed or is it just left lost in the Code[] space? I'm not planning on removing anything from the symbol table. > I notice that the interpreter does a quick scan of the symbol table to try and > match > a literal. I don't know if this is normal for interpreters or compilers but I > think > that it is pretty cool. One optimization should be that func() or proc() > would return > the same routine_id for a function that was already defined. I don't know what you mean here. > Maybe the IL code could be stored in the variable space and added and removed > from > the Code[] space as needed? If you examine how the interpreter does things, there's really no difference between 'Code' space and variable space. SubPrograms (including one for TopLevel) contain a code section. The CurrentSub is constantly changed, so that the interpreter executes code from different places all the time. > Also, I realize that this would not work with RDS official backend. Shrouded, > bound, > or translated programs would need to include the proper files from the > interpreter. > Hmm. It could probably still work with RDS backend but you would have to > include > the interpreter code just for the eval-type functions. Actually, I don't think it would work quite that simply, because there would be no way to touch any symbols in your program through eval(), other than a giant, manual if-elsif that updated your variables, which would need to be changed for each program. Matt Lewis