On Thu, Jun 02, 2005 at 09:14:33AM +0200, "TSa (Thomas Sandla▀)" wrote: > Patrick R. Michaud wrote: > >Of course, there are other "implicit" parameters that are given > >to a rule -- the target string to be matched and an initial > >starting position. But I think some of those details are still > >being worked out. > > Wasn't it said that rules have the current match object/state > as invocant? I would assume that everything else can be found > through it? Actually the mnemonics that $/ is the match and > methods on $?SELF are called with ./method fits. The only > remaining thing is to define the method set of the Match class.
Alas, it doesn't seem to be quite that straightforward. Or maybe it is, and I'm just not seeing it yet. So, I'll just "think out loud" here for a bit... If the current match object/state ($/) is the invocant of the rule, then in order for rule inheritance to work properly $/ must be able to be an instance of a Grammar. A05 explicitly recognizes this possibility when it says "the state object may in fact be an instance of a grammar class". If that's the case, we might not need a separate C<Match> class, and we just place the methods needed for inspecting "match objects" into the Grammar class. But somehow my brain just has trouble accepting that applying a rule to a target returns an "instance of a Grammar". The wording seems all wrong, or perhaps I just need to adjust what I think of when I see the word "Grammar". Getting rule inheritance to work properly is a bit tricky. When confronted with something like "label: x = y + z" ~~ rx :w / (\w+) \: <Foo::expr> / we have to create at least two match objects, and if we say that the match objects are the rule invocants, then the grammar engine has to be smart enough to recognize that the match object it creates to use as the invocant of <Foo::expr> is an instance of grammar Foo. Or, perhaps Foo::expr and all rules in Foo are really constructors of some sort that build Foo objects--that seems more logical. But if we say that Foo::expr is a sub or method that constructs Foo objects (as opposed to having a pre-existing invocant), then Foo::expr needs to have the target string and starting position available to it somehow, as I mentioned in my previous message. On another topic, what do we do with rules that aren't members of a grammar? A05 says: Within a closure, C<$_> represents the current state of the current regex, and by extension, the current state of all the regexes participating in the current match. (The type of the state object is the current grammar class, which may be an anonymous type if the current grammar has no name. If the regex is not a member of a grammar, it's of type RULE.) I suspect the first sentence is out of date -- that C<$_> above is now really C<$/> (the match object). Since in the case of a bare rule we don't have a "current grammar", what can we say about the type of the state object beyond "it may be an anonymous type"? 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). Or perhaps all of this is to resolved using roles, mixins, or multiple superclasses. But to get back to my original statement that "some of the details are still being worked out", I find that A05 is somewhat speculative on many of the details of how grammars, inheritance, state objects, and rules will interact, and S05 is practically silent on the topic. So, there's definitely some work to do. And of course we have to figure out how to map all of this into what Parrot has available, or update Parrot to provide what we need to do this. :-) I'll be appreciative of any illumination that others can provide to the above, especially from @Larry. Pm