Re: Thoughts on eval()

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

Matt Lewis wrote:
> No, I think it's easier to simply treat what's passed to eval() as more code
> for euphoria to parse and execute.

That's exaclty what I'm saying.  Only what gets passed to eval() gets added in
to the rest of the code.

> > 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.

It was a bit of a tangent -- nevermind.


>  
> > 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.

Okay.  I didn't quite get that far.  From what I could see is that all the
parsed IL code went into the Code[] sequence.  Names of functions in SymTab[][]
had a field that pointed to the proper place in the Code[] sequence.  I still
don't have a full understanding of it, though.

>  
> > 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.  

Good point.  It could still be used with bound/translated etc. programs but
couldn't share any symbols.  And it would be slower.

> 
> Matt Lewis
> 


=====================================
Too many freaks, not enough circuses.

j.

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

Search



Quick Links

User menu

Not signed in.

Misc Menu