At 6:23 PM +0100 11/9/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> 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
Dan Sugalski <[EMAIL PROTECTED]> 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
At 3:42 PM +0100 11/9/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
This was specified ages ago
You have skipped one question:
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
Dan Sugalski wrote:
This was specified ages ago
You have skipped one question: how would PIR code of this eval() look
like, and specifically, what about that "goto"?
# #! perl -w
# my $i= 5;
# LAB:
#$i++;
#eval("goto LAB if ($i==6)");
#print "$i\n";
#
# 7
#
You can of course answe
At 1:48 PM +0100 11/8/04, Leopold Toetsch wrote:
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 w
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?
Does the compiled code see Parrot registers of the call
