On Jan 24, 2008 5:45 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> 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
One more common construct is the switch statement, especially if the
language has "fall-through" semantics for the cases (so no implicit
"break"). I think Perl 6 (given statement) has implicit breaks, so that only
the selected case is executed. Many other languages that will be dealt with,
let control fall through the cases, which is a pain to implement by hand. It
cannot be done simply by creating :pasttype('if') nodes, as that will only
execute the <then> block (first child). It would be nice to have some kind
of 'switch' node (IIRC, the JVM even has a special instruction for that),
that takes a list of 'case' conditions, and the blocks (or maybe better
would be a 'case' node, taking a 'condition' child and a 'block' child, that
is executed. The 'switch' node could be a specialized version of 'Stmts',
that takes these 'case' nodes as children, and has an attribute
'fallthrough' or whatever).
Maybe I'm thinking on a wrong level here, but I think it would certainly
help to have some PAST support here.
Just another thought :-)
kjs
