Re: Thoughts on eval()
- Posted by Jason Gade <jaygade at yahoo.com> Dec 14, 2004
- 509 views
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.