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