On Sat, Jan 19, 2008 at 12:24:37PM +0100, Klaas-Jan Stol wrote:
> as far as I could tell there's no support for goto statements in PCT (that
> is, special nodes or something).
> I don't know whether there are any plans to add special support for it, but
> here's an idea I was thinking about. It would be rather helpful, instead of
> having this handle by each language implementer, by manually generating
> (:inline) statements that result in a label and the relating "goto"/"jump"
> statements; it's a pretty common feature.
>
> Statements like "break", "next", "last", "continue" typically take a label
> as an argument (or it's implicit like for "continue").
You're correct that PCT doesn't have support for 'goto' yet, and
yes, it will. However, the typical model for this is likely to
be based on control exceptions instead of using branches and labels.
To borrow from your example:
> while ($x < 10) {
> $x++;
> next if $x < 5;
> print $x;
> }
In Perl, the { ... } represents a new lexical scope, and in the
general case that means it's a separate Parrot sub with an
:outer flag. Thus when we determine that we need to invoke 'next',
we can't do it with a simple branch, we need to throw an exception
that gets caught by the while loop in the outer Parrot sub and
handled there.
The same is true for labels on the control exceptions, such as
"next LABEL" -- in this case the control exception propagates
outward until it reaches the construct having the corresponding
label.
A similar situation exists for 'return': because it's possible
to invoke a return inside of a nested lexical block, it needs to be
treated as a control exception that can propagate outward through
outer lexical Parrot subs until it reaches the outer block of
the higher-level sub and gets returned from there.
I haven't completely figured out how we'll handle 'goto' statements,
but I'm suspecting it will also need to be based on control
exceptions as opposed to simple PIR branches.
It's possible that some HLLs or situations may warrant optimizing
control statements to use branches instead of control exceptions --
e.g., when the body of a loop isn't a nested lexical block.
But I think we're better off saving that as a later optimization
than trying to resolve it now.
So, the next step on this issue will likely be for PCT to define a
relatively standard interface for its control exceptions, and then
adjust its node types to be able to throw and catch the control
exceptions as appropriate.
Thanks!
Pm
