Damian Conway wrote:
> One possibility is that a modifier is
> implemented via a special class:
>
> my class Decomment is RULE::Modifier
> is invoked(:decomment) {
> method SETUP ($data, $rule) {
> ...
> }
> # etc.
> }
I'm messing around with regex code generation by
converting first to a grammar. The modifiers seem
to need intimate knowledge of regex -> grammar
conversion. This may be a quirk of my approach.
People using tree traversal or generating code
directly from the regex might see something else.
I suspect modifiers will still be deeply connected
with the internals.
Is this why you're thinking of modifiers as
classes? So the modifier can guide the regex
engine (tree generator, code generator, etc.) by
hooking in at certain spots? (I don't envy the
job of standardizing those hooks -- it seems like
every modifier I've thought of needs a different
hook.)
One alternative I was thinking of is treating
modifiers as filters -- something like a tree
transformation language that runs after the core
has parsed a regex. I like filters because they
don't need much knowledge of the regex engine.
They're slower though, so maybe a combination of
the two would be best. Built-in modifiers like :w
and :i could be embedded in the core, but user
defined modifiers could be filters. (Some
modifiers are really just new rules in disguise.
Those are the easiest kind. For example :p5 could
just be an attribute checked by the <regex> rule:
rule regex { <($p5)> :: <p5_regex> | <p6_regex> }
Oh. Wait. That should be 'rule' not 'regex'... ;)
BTW, what code is legal in a grammar block? Can
we introduce new lexicals? I'd like to write
something like this:
grammar foo {
my $parsing_x;
rule x { { let $parsing_x = true } ... }
rule y { <($parsing_x)> ... | ... }
}
(Hypotheticals are so cool!)
It's no big deal to put the grammar state in an
outer block, but I like the idea of treating
grammars like classes.
- Ken
