Q: eval
Leopold Toetsch
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?
Does the compiled code see Parrot registers of the caller or is it more
like a function call?
What about register preserving?
And finally what shall we do with such branches:
# #! perl -w
# my $i= 5;
# LAB:
# $i++;
# eval("goto LAB if ($i==6)");
# print "$i\n";
#
# 7
#####
.sub _test
I1 = 5
$S0 = ".sub _e\nif I1 == 6 goto LAB\nend\n.end\n"
compreg P2, "PIR"
compile P0, P2, $S0
LAB:
inc I1
invoke
print I1
print "\n"
end
.end
Force them to be continuations?
leo
Dan Sugalski
>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
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Dan Sugalski
>Dan Sugalski wrote:
>>
>>This was specified ages ago
>
Nope. Language designer call. (Granted, in this case if the call is
"make it work" then the language designer and I get to have a chat,
but... :)
>how would PIR code of this eval() look like, and specifically, what
>about that "goto"?
That goto's bogus and shouldn't work. I think it does right now, but
I'm OK with making it not work -- it *shouldn't*, since in perl the
eval's an anonymous sub, which means you've done a goto out of a sub
and into another, which... well, that's not supposed to work.
># #! perl -w
># my $i= 5;
># LAB:
># $i++;
># eval("goto LAB if ($i==6)");
># print "$i\n";
>#
># 7
>#####
I can see this having some ramifications for languages with REPL
facilities and goto, but I'm not sure I have a problem with that not
working right.
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
>
>> That goto's bogus and shouldn't work. I think it does right now, but
>> I'm OK with making it not work -- it *shouldn't*, since in perl the
>> eval's an anonymous sub, which means you've done a goto out of a sub
>> and into another, which... well, that's not supposed to work.
>
This surprises you? :)
I'm not sure exactly how this ought to be handled. I suppose it could
be done with a GOTO exception if the label's not found in scope.