> > The reason for the modifier (or even a new operator (g/" for example) is that
> > you can easily test your regular expressions. The interface is trivial - all you
> > have
> > to do is switch your m/ out for g/, and sit back and see how your patterns
> > translate
> > into strings.
>
> Yeah, that looks pretty easy. Until you see what that looks like in a
> program. What does it mean to change an m// to a g//?
>
> if $str ~~ m/foo bar/ {...}
well, yeah, but I'm not saying to modify it insitu. I'd be perfectly happy with
yanking out the regex, sticking it into a context that makes sense, and
then genning away (in temporary scripts if necessary). Either that or making
the regex a rule to be used in two places..
> > If you need to match the regex engine in reverse, in a totally unattached way
> > via subroutine, then I would think the chance for subtle mistakes and errors
> > would be exceedingly great.
>
> I don't understand how.
it means that you have to reimplement - in reverse - the logic of the regular
expression engine in a separate place. I'd like to tie the testing of the
regular expression engine to the generate engine - the closer the tie the better.
In 'make test' if necessary).
That way, any change to the regular expression engine is guaranteed to be
added into both places:
@gen = g:bnd(1000)/<[ab]>+/
if (@gen !~ m/<[ab]>+/) { print STDERR "something is seriously wrong..\n"; }
or maybe even
(g:bnd(1000)/<[a-b]>+/ !~ m/<[a-b]+>/) && print STDERR "SOMETHING IS SERIOUSLY
WRONG"\n;
I suppose generate could be distributed in a standard module (to get the
same effect) but its a question of how 'basic' the function is going to be, and
how many modifiers that it could possibly have. I could see many different
ways of genning the strings for a given grammar, for example ':bnd' just taking
boundary cases (<[a-z]+> translates to a,z,aa,az,etc)
:depth (for depth-first search), :breadth (for breadth first search),
:lazy (for lazy generation of patterns), etc.
> I'll show you. Here are some of the generators. This is very dense,
> functional code. Read at your own risk (but I'm certainly not writing
> it to be executed!).
yes, i see this is cool. I'd just hope that there would be an equivalent set of
rules that matches the entire regular expression engine, and distributed with
the 'standard' perl6 distribution if there is such a thing.. And that there isn't
too much of a performance hit in the case of extreme recursion.
Ed
