Larry Wall writes:
> On Wed, Mar 10, 2004 at 12:42:00PM -0700, Luke Palmer wrote:
> : I can think of a couple that I like better:
> :
> : <^foo>
> : <*foo>
> :
> : <^foo> is my favorite at the moment (even though <*foo> is more
> : visually pleasing), because it looks like it's transferring the
> : information ^up^ in the parse tree.
>
> But $^foo and $*foo mean very different things from hypotheticals.
>
> And in a real sense $?foo is passing guessed information *down*
> the match. The guesses only turn out "right" if you get all the way
> to the bottom successfully. (That's from the point of view that
> you recurse deeper to check anything to the right in a regex, even
> when syntactically it's shallower.)
Hmm... that makes sense.
It doesn't feel right, though. After all, we don't say:
($minutes, $seconds) = m/ (? \d\d ) : (? \d\d ) /;
Even though they only stay matched if they get to the end without
backtracking. Capturing (this is really just a clever notation for
captures) is usually about communicating information I<outside> of the
match: to the parent rule, to the the calling scope.
As you showed in your reply about C<.=>:
macro postfix:.= ($lhs, $parsetree)
is parsed(/<ws>? <?method_name> <?method_args>/)
{ ... }
There's nothing about C<?> that makes me think that these are being
stored.
I understand the association with C<$?foo>. But most of the time, when
I'm writing a grammar, I'm catching these rules in order to stick them
in the parse tree, not to do tests on them later on in the rule. The
very essence of rules is hypotheticality, where nothing is permanent
until it gets to the end. I don't think we need a special marker that
says "these do that, too."
Luke
