develooper Front page | perl.perl6.language | Postings from April 2006

Re: [svn:perl6-synopsis] r8883 - doc/trunk/design/syn

Thread Previous | Thread Next
Patrick R. Michaud
April 20, 2006 07:25
Re: [svn:perl6-synopsis] r8883 - doc/trunk/design/syn
Message ID:
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, 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.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About