develooper Front page | perl.perl6.language | Postings from June 2005

Re: comprehensive list of perl6 rule tokens

Thread Previous | Thread Next
Patrick R. Michaud
June 2, 2005 14:17
Re: comprehensive list of perl6 rule tokens
Message ID:
On Thu, Jun 02, 2005 at 09:19:22PM +0200, "TSa (Thomas SandlaƟ)" wrote:
> >I think the state object ought to have some sort of base type -- 
> >is it Grammar?  Rule?  If we say it's a "Rule", then we're 
> >effectively saying that "applying a Rule to a target results 
> >in a Rule object containing the state of the match", which just
> >sounds completely wrong to my ears/eyes (even though it may in 
> >fact be correct).
> It sounds perfectly to my ears. You should think of ordinary
> subs as classes and calls to them as instances of that class.
> The environment created at runtime for such an invokation actually
> *is* a sub object. [...]

Okay, viewing it that way makes me quite a bit more comfortable with it.  
I've also re-read parts of A05 (and S12 and S06) that seem to help 
to clear things up a bit.  Specifically, A05 says

   In this case a rule is simply a method in a grammar class, 
   and a grammar class is any class derived implicitly or 
   explicitly from the universal [Rule] grammar class.

I take from this that

    grammar Foo { ... }

creates a class Foo derived from Rule, and any rules declared in the
braces are (class) methods of Foo that create instances of Foo.  
Combined with other statements, this also means that match objects are 
instances of either Rule or the grammar method used to create them.

I also guess this means we really don't need a C<Grammar> type
as mentioned in S06, since that's being covered by Rule.  Or
perhaps Grammar is an abstract subclass of Rule and the C<grammar>
statement derives new grammars from Grammar.

A05 also mentions

    The built-in regex assertions like C<< <before \w> >> are 
    really just calls to methods in the [Rule] class.

which works well for me for the time being.

So, returning to invocants, and throwing in lexically scoped rules
to boot, consider the following.  (This may more properly belong on
p6c, but since the thread started here I'll keep it here for a message
or two until it becomes obvious it belongs somewhere else.)

    grammar Foo {
        rule alpha { <[abcdef]> }
        rule beta  { <alpha>+ <digit>+ }

    my rule alpha { <[uvwxyz]> }
    my rule beta { <alpha>+ <digit>+ }

    m :w / <beta> <Foo::beta> /

We have to get the code for each of the two "beta" rules to properly 
dispatch to the appropriate grammar-scoped or lexically-scoped rule,
and get the appropriate invocant.  The process appears to be:

    1. If the subrule is scoped (e.g., <Foo::beta>), then dispatch
       to Foo.beta(target,pos).
    2. If the subrule is not scoped (e.g., <beta>), then look for
       a lexically-scoped subrule of the same name -- i.e., 
       beta(target, pos) and call that if it exists.  Otherwise, 
       call $/.beta(target, pos).  

In each case, the subrule returns a match object of the same type 
as its "invocant".

Or something like that.


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