Re: Apocalypse 5 and regexes

[kvale]

All the apocalypsi up to this point have been incremental, but this one changes everything in the regex world. In fact the system that Larry proposes is so far beyond what computer sceince calls regular expressions, it should be given a new name.

I would propose grammar expressions, or gramexes, because this system will allow one to parse full recursive grammars easily. I'd guess Larry chose angle brackets because that is what is often used in specifying nonterminals in a BNF grammar.

From the implementation point of view, such a system will require the full intermixing of perl and gramex code at the Parrot bytecode level, which will probably slow down matching relative to the perl5 regex engine.

From a user point of view, I think the difference between temp and let and local and my will be pretty confusing for most users.

Previously, grammars had been parsed by perl code for the parsing and regexes for the lexing. Larry seems to be betting that a specialized subsystem for grammars will be more readable and perhaps faster than the old way.

Times will certainly be interesting for perl6 gramex implementors.

[Elian]

"Interesting" is one way to put it, yep. :)

Still, it shouldn't be that bad. Most of what A5 calls for that's new is needed for Parrot's parser anyway, so there's a serious overlap there, which means we can do it all just once and save some time and effort.

Perl 6's regexes may be slow, but I'm not sure that'll really happen. One thing that will help is the JIT, which will reduce some of the time eaten up by bandwidth issues. The single biggest time sink with making these Parrot opcodes is that everything involved with parrot opcodes is 32 bit, while perl 5's regex bytecode engine is all 8-bit. (And yes, the perl 5 regex engine is a bytecode engine too) That means wer're moving four times as much data across the processor bus. OTOH, it's naturally aligned, which helps, and if things stay in L1 cache it's not a problem anyway. It's the initial cache load, and the times when things spill out of L1 cache, that really hurt.

There's a fair amount we can do about that, and I'm more than happy to put in as much cheating as we need to for speed reasons. (At the moment, the single biggest reason that perl 5's regex engine is faster than a comparable one in Parrot is that perl 5's regex engine does a lot of optimization of the search, which'll make a huge difference)

[graff]

I also think "gramex" is a bit clunky. But grammars mean parsing. I assume that "parsex" would be a bit too "volatile" and open to unrelated criticism.

The shorter "parex" might be about right; there might be wars about the "correct" pronunciation ("Parsing :: parex." "No! Parrot :: parex!"). So what?

Eventually, of course, we'll all want to shoot the person who puns about the "parex par excellence!" for the thousandth time...

[ariels]

"Gramex" sounds... weird. To me, at least. And (to steal a phrase off the Wall) it's bad Huffman coding.

Why not "grex" (and, presumably, many "grexen")? It's better, after all, than what you use to grep on UN*X.

[Anonymous Monk]

'gramexes' just doesn't quite have the ring of 'reglexes' and 'regyaxen' proposed in this node. Something like 'yacclexen' might be more correct but sounds even worse than gramexes. Anyone else got a good nickname for Perl6's non-regular expressions?