Re: Thoughts on eval()

new topic     » goto parent     » topic index » view thread      » older message » newer message

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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu