First, let me say I really like the changes to S05. Good work
once again.
Here are my questions and comments.
On Thu, Apr 20, 2006 at 02:07:51AM -0700, [EMAIL PROTECTED] wrote:
> -(To get rule interpolation use an assertion - see below)
> +However, if C<$var> contains a rule object, rather attempting to
> +convert it to a string, it is called as if you said C<< <$var> >>.
Does this mean it's a capturing rule? Or is it called as
if one had said C<< <?var> >>? (I would prefer it default
to non-capturing.)
> +If it is a string, it is matched literally, starting after where the
> +key left off matching.
> ..
> +If it is a rule object, it is executed as a subrule, with an initial
> +position after the matched key.
> ..
> +If it has the value 1, nothing special happens except that the key match
> +succeeds.
> ..
> +Any other value causes the match to fail. In particular, shorter keys
> +are not tried if a longer one matches and fails.
Is there a way to say to continue with the next shortest key?
> +Note: the effect of a forward-scanning lookbehind at the top level
> +can be achieved with:
> +
> + / .*? prestuff <( mainpat >) /
That should probably be
/ .*? prestuff <( mainpat )> /
> +As with bare hash, the longest key matches according to the longest token
> +rule, but in addition, you may combine multiple hashes under the same
> +longest-token consideration like this:
> +
> + <%statement|%prefix|%term>
This will be interesting from an implementation perspective. :-)
> +It is a syntax error to use an unbalanced C<< <( >> or C<< )> >>.
On #perl6 I think it was discussed that C<< <( >> and C<< )> >>
could be unbalanced -- that the first simply set the "from"
position and the second set the "to/pos" position. I think I
would prefer this.
Assuming we require the balance, what do we do with things like...?
/ aaa <( bbb { return 0; } ccc )> ddd /
And are we excluding the possibility of:
/ aaa <( [ bbb )> ccc
| dd ee )> ff
]
/
(The last example might be the anti-use case that shows that
<( and )> ought to be properly nested and balanced.)
> +Conjecture: Multiple opening angles are matched by a corresponding
> +number of closing angles, and otherwise function as single angles.
> +This can be used to visually isolate unmatched angles inside:
> +
> + <<<Ccode: a >> 1>>>
Does this eliminate the possibility of ever using french angles
as a possible rule syntax character? (It's okay if it does,
I simply wanted to make the observation.)
> +Just as C<rx> has variants, so does the C<rule> declarator.
> +In particular, there are two special variants for use in grammars:
> +C<token> and C<parse>.
I agree with Audrey that C<parse> is probably too useful in other
contexts. C<token:w> works fine for me.
> +With C<:global> or C<:overlap> or C<:exhaustive> the boolean is
> +allowed to return true on the first match.
Nice, nice, nice! Makes things *much* simpler for PGE.
Pm
