Returning from Rules

[Luke Palmer]

I notice that when I write a grammar, I end up doing this an awful lot
(in P::RD notation):

list: term ',' list { make_node(@item[0,1,3]) }
| term { $item[1] }

With attention on the actions, and assuming <autotree> is on.

In Perl 6, aside from the fact that there's a clearly better way to
write this rule, this would be translated:

rule list {
<?term> , <?list> { $0 = make_node('list', $?term, $?list) }
| <?term> { $0 = $?term }
}

The part that I'm complaining about in this mail is C<$0 = >. While
it's only three extra characters, I believe that it is a large hindrance
to readability. However, we can reclaim this readability by noticing
that the construct:

<{ get_rule() }> # call an anonymous rule returned by the code block

Can also be written:

<$( get_rule() )>

Because of the interpretation of:

<$somerule>

Therefore, the first syntax can be redefined to evaluate the code block
and assign the result to $0. The example now becomes:

rule list {
<?term> , <?list> <{ make_node('list', $?term, $?list) }>
| <?term> <{ $?term }>
}

My argument for using this notation stems from the fact that it would
be a royal pain to write subs like:

sub add ($a, $b) {
$RET = $a + $b;
}

Even though it's just a few extra characters. I don't want to think
about replacing the current parse tree node, I just want the rule to
represent a value. An assignment has little place there.

Luke

[Smylers]

Luke Palmer writes:

> <{ get_rule() }> # call an anonymous rule returned by the code block
>
> Can also be written:
>
> <$( get_rule() )>
>

> Therefore, the first syntax can be redefined to evaluate the code block
> and assign the result to $0. The example now becomes:
>
> rule list {
> <?term> , <?list> <{ make_node('list', $?term, $?list) }>
> | <?term> <{ $?term }>
> }
>
> My argument for using this notation stems from the fact that it would
> be a royal pain to write subs like:
>
> sub add ($a, $b) {
> $RET = $a + $b;
> }

This sounds sensible to me -- not something I'd normally bother saying
(a surprisingly high number of the mails on this list sound sensible to
me), but I thought this could do with some deWarnockization ...

Smylers

[Jeff Clites]

On Apr 19, 2004, at 12:06 AM, Luke Palmer wrote:

> Therefore, the first syntax can be redefined to evaluate the code block
> and assign the result to $0.

Would you ever want to leave $0 unaltered? That's the only concern
which comes to mind.

> My argument for using this notation stems from the fact that it would
> be a royal pain to write subs like:
>
> sub add ($a, $b) {
> $RET = $a + $b;
> }

I think Pascal does something like this.

JEff

[Luke Palmer]

Jeff Clites writes:
> On Apr 19, 2004, at 12:06 AM, Luke Palmer wrote:
>
> >Therefore, the first syntax can be redefined to evaluate the code block
> >and assign the result to $0.
>
> Would you ever want to leave $0 unaltered? That's the only concern
> which comes to mind.

Absoultely: if you want side-effects while building the default parse
tree. But then you just use a regular {} block instead of a <{}> block.

Luke

[Larry Wall]

On Mon, Apr 19, 2004 at 01:06:29AM -0600, Luke Palmer wrote:
: Therefore, the first syntax can be redefined to evaluate the code block

: and assign the result to $0. The example now becomes:
:
: rule list {
: <?term> , <?list> <{ make_node('list', $?term, $?list) }>
: | <?term> <{ $?term }>

: }

Well, I've been thinking about this for a couple of weeks now, and
while I freely admit that "$0 =" is ugly, I also find that I dislike
using <...> for something that is not a pattern assertion, but a
side effect. Plus your proposed notation is almost as long as what
you're replacing. And I don't think it stands out visually enough
for its semantic weight.

: My argument for using this notation stems from the fact that it would

: be a royal pain to write subs like:
:
: sub add ($a, $b) {
: $RET = $a + $b;
: }
:
: Even though it's just a few extra characters. I don't want to think
: about replacing the current parse tree node, I just want the rule to
: represent a value. An assignment has little place there.

Then what you want is something like a "return" keyword, only it returns
from the rule rather than the closure:

rule list {
<?term> , <?list> { succeed make_node('list', $?term, $?list) }
| <?term> { succeed $?term }
}

Or whatever word you like there...

Alternately, you can get rid of the explicit $0 by saying

rule list {
<?term> , <?list> {.= make_node('list', $?term, $?list) }
| <?term> {.= $?term }
}

That at least removes the extraneous "noun" from your thinking, and
".=" can be read as a pure verb if you like. And if you don't like,
translating "succeed" to ".=" via a macro is left as an exercise for
the don't-liker.

Larry