> How do you do that? Generation and matching are two different things
> algorithmically.
yes, but they are intimately linked. just like the transformation of a string
into a number, and from a number to a string. Two algorithmically different
things as well, but they'd damn-well better be exact inverses of the other.
It all comes down to what you think is a 'low level' op.. Some languages
think that regular expressions themselves aren't low level enough to be
included in the language, perl thinks that it is low-level enough to be an op.
My point is that if inputting strings into grammars is low level
enough to be an op, why isn't generating strings *from* grammars?
Anyways, that's my main point.. anyone who wants to read further for more sub-points
on why I believe this to be true, proceed at their own risk..
> > @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
>
> Or even a nonstandard module. That's my point.
> Let me come right round to my point about perl being open source.
> Someone has to do the work somewhere, and making it "standard" or "core"
> doesn't change that. It just means that it'll take longer.
well, of course. But its not something that needs be included in the first
iteration. As far as I know, making g// as an operator (or adding a modifier
to m//) doesn't change the perl6 parser in any way.
My suggestion is that doing it at this low level will help stress test
the regex engine, and it would be useful to have in 'make test'. And hence it
makes sense as either a low-level module or op.
IMO Its always helpful to see a problem from two different angles - and if a
g:// !~ m// equation comes up true, something is either extremely wrong
with the regex engine or something is extremely wrong with the generator.
And if there was a way to 'coverage test' your regular expressions (so that
you could be sure that all regex alternations were tested) then you could
use the regex engine to stress test the generator.
> Making "standard" also doesn't make it any faster. You have to burn the
> cycles somewhere along the line in any case. The algorithm is
> recursive, and that's a mathematical truth. If you can find a
> nonrecursive algorithm, please do so, and then you can put it in a
> module.
of course, but making it 'standard' - and especially making it so that it
is part of the regression test suite - gives it incentive to be complete
and the incentive for people to make performance improvements and perhaps
code it in IMCC/parrot byte code.
Plus, it gives it incentive for *standardization* - I could see lots of
partial solutions out on C6AN for the generator problem when only one is
really needed - one that totally matches the regex engine. Its just like
dates and times - CPAN is a veritable sink for half-implemented solutions,
where if we had a single standard people's lives would be a lot easier.
> I think we should all settle on the fact that any feature could be
> considered "standard", but very few probably should. And what is is
> Larry's decision, and I think we should leave it at that.
Look, to a certain extent I agree with you, and I don't want to belabor
the point. Let me just say that this is my attempt at lobbying the decision
making process.. ;-)
Ed
