First off, I'll point out that this belongs on p6l and nowhere else.
Edward Peschko writes:
> 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.
An 'op'? What's that?
An 'operator' is a syntactic construct in the language, and can be
defined by anyone, anywhere in Perl 6.
An 'opcode' is a Perl 5 thing that has no meaning in Perl 6. If you
want to talk about 'opcodes', you ought head over to p6i. And this
discussion less belongs there than it does on perl6-compiler.
> My point is that if inputting strings into grammars is low level
> enough to be an op, why isn't generating strings *from* grammars?
Because nobody's implemented it yet. [I'll refer to this later, let's
call it [Because]]
> 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.
I'll agree with you there. It would be a valuable tool in the regex
test suite...
Not that we don't have enough regex tests...
Not that we ever have enough regex tests...
Hmm. I guess it all comes down to [Because].
> 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.
Of course, what you really want to do is test whether your regexes are
matching what they're supposed to, not that they're matching what
they're matching.
> > 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.
And what does coding it in IMCC (I doubt anyone will code it in byte
code :-) give you? Speed? Why do you need that for this kind of
feature?
> Plus, it gives it incentive for *standardization*
See chromatic's reply.
> - 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,
And quite the sink for completely implemented solutions. And quite the
sink for very useful half-implemented solutions.
> where if we had a single standard people's lives would be a lot
> easier.
There is a class of people whose lives wouldn't be a lot easier. I'm
one of them.
And watch, I'll alleviate their pain, by bringing it upon my shoulders:
% perl -MCPAN -e 'install "Grammar::Generate"'
> > 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.. ;-)
Oh, and don't think that I'm annoyed by your doing so (no sarcasm
intended (there, either)). I've been lobbying the process for
years... :-)
Luke
