I'd like to cleanup eval.pmc and dynamic code compiling a bit. But before that I'd like to know:
Which granularity do we allow for eval()ed code?
Can that be an expression or statement too or is it always at least an (anonymous) subroutine?
This was specified ages ago -- I don't know where the confusion is coming in.
There is no eval operation as such. Things like perl's eval do:
1) the source is passed to the language compiler module, which returns a sub PMC representing the code
2) That sub pmc is then invoked just like any other sub PMC
What happens as part of the compilation is language dependent. Most of the languages we care about have well-defined semantics for it, and even if they didn't it's not for us to dictate what those semantics are.
For PIR/PASM code, which is ours, the semantics are the same as PIR/PASM is now.
PASM doesn't need defined compilation units, and the returned sub just represents the whole wad of source. Invoking it jumps to the start and goes. (So the code has to do the calling convention stuff itself, which isn't any different than any other code)
We went around on PIR code before -- I thought you'd already defined it. If not, then the rules are essentially the same as the rules for bytecode. The returned sub is the one tagged @MAIN, and any sub tagged @LOAD gets executed before the compilation returns. If no sub is tagged @MAIN then the returned sub PMC does nothing.
This arguably means that the load_bytecode op should have a version that returns the @MAIN sub object, and that @LOAD should be unconditionally executed for loaded bytecode. We've already gone over that one before, though.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
