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
