"Group of named regexes that form a formal grammar"
Are Perl 6 "regexes" as powerful as a context-free grammar? I guess they use the same kind of backtracking algorithm and ad hoc recursion as Perl 5? That is, does the algorithm for regexes differ from Perl 5, or only the syntax?
I think the syntax is a big improvement BTW.
TL;DR If you can code it, you can code it using Perl 6 grammars.
Perl 6 is designed as a collection of "slangs" (short for sub-languages) that recursively embed each other. (There are about a half dozen slangs in standard Perl 6 but you can add more.)
So the full power of the "main" Perl 6 slang is available within the regex slang (and vice-versa). During execution each slang automatically tracks the interesting state of the other slangs.
So, while the compiler is free to analyze a given rule and generate a suitably optimized DFA or NFA, they are, in general, capable of turing complete power.
> I guess they use the same kind of backtracking algorithm
The main answer is No.
There are four types of "rule". Only one of these, using the `regex` declarator, backtracks in the usual regex way.
Most extant grammars contain nothing but `rule`s, `token`s, and occasionally `method`s.
The fact that the latter are just ordinary methods hints at what's going on; the "regex slang" is really just a built in recursive ascent/descent parser generator with a convenient DSL (slang) for writing grammars.
In Perl 6 regexes are seen as a type of method (that is they are literally implemented as a type of method in Rakudo)
Grammars tend to look like a cross between BNF, and well Perl. https://stackoverflow.com/a/41770672/1337
Perl 6 regexes have longest term matching using |, or sequential matching like Perl 5 using ||.
Since regexes are methods, they can take arguments as well.
So it's basically a mix of paradigms, which muddies the waters in terms of what computational complexity guarantees you can get. Pure regular expressions can be matched in linear time; CFGs in cubic time and some subsets in linear time; packrat parsing in linear time, and backtracking PEG in exponential time. Perl 5 regexes are exponential time in general.
I've used regexes extensively on big data so I don't like this mix of paradigms. I'd rather have separate dialects for each paradigm than having to guess what it's using underneath.
Backtracking causes real problems in production: https://news.ycombinator.com/item?id=12132045
I would bet money that Perl 6 uses backtracking, because it has a mix of paradigms that makes it harder to do anything smarter.
Backtracking is also bad for adversarial input, which is essentially always a concern nowadays.
Please do have a play some time and assuming that I got the above right, donate however much money you would've been willing to bet to the Perl Foundation or the Enlightened Perl Organisation as you prefer :)
I'm not saying nobody wants Perl to work like that... but I am saying I wouldn't use such a tool. It's not right for the problems I need to solve.
I also think it's good if programming languages use algorithms with well-known behavior, rather than a mish-mash of heuristics. Heuristics are OK if there is nothing better known, but these problems have been studied.
Basically: Perl 6 tokens and rules imply :ratchet, which means no backtracking. You can use raw regexes if for some reason you do need backtracking, but otherwise it looks like a Perl 6 grammar is backtracking-free (and grammars in the real world hopefully use tokens/rules exclusively).
So it might actually be at least tolerable for the problems you need to solve (though it's hard for me to say without knowing the problems in the first place (: ). The main remaining question is the exact algorithm in use; I'd be very surprised if Perl 6 grammars didn't compile down to at least some variation on packrat parsers, which would mean linear complexity, but this is probably - again - implementation-dependent in the "we don't care what you do so long as it passes the Perl 6 test suite" sense. I've yet to find a definitive answer by spelunking through Rakudo's code, but it's reassuring that even Rakudo's grammar for Perl 6 itself seems to be devoid of backtracking (meaning that it's clearly possible to do without it; there are quite a few generic subs/methods in there, though, which could prove me wrong here).
With tokens another nice thing to note is there is longest token matching and the concept of "proto" tokens and regexes. This lets you have simple decision making between similarly defined tokens without backtracking. For example the grammar I have for biological sequences can simultaneously identify and parse DNA/RNA/Protein without back tracking. Even if a file has a mixture of data I can instantiate the correct subclasses on the fly whilst parsing! https://github.com/MattOates/BioInfo/blob/master/lib/BioInfo...
And yeah, proto regexes are pretty sweet, and they seem to be a natural fit for what you're doing. I'm always surprised by how popular Perl seems to be in biology / life sciences, and projects like BioInfo (and BioPerl, of course) are a great reminder as to why that happens to be.
I've used Perl 6 for IRC bots. The ease of writing parallel code, nice OO model, multi dispatch, and subsets make it very pleasant to do them in Perl 6. Here's a bot I wrote that listens for GitHub webhooks and reports new commits and PRs: https://github.com/perl6/geth and here's another one that's just a bunch of random features: https://github.com/zoffixznet/perl6-buggable/
I also heard people say grammars are the most note-worthy feature of Perl 6 and people basically use them to quickly hack up a nice little micro-language in which they then attack their problem. Before I came to Perl 6 I was dumb as shoe when it came to writing parsers, but I find it trivial to do with Perl 6 grammars.
Do I like it? Although I'm obviously biased, I love the language. It lets you write beautifully concise, yet still readable, code. It even lets you use much more readable syntax for regexes. Somewhat regretfully, it made it very difficult for me to learn other languages, as in them I end up writing 3x, 4x, 6x the amount of code and I keep getting reminded of Larry Wall saying Perl 6 would be the last language you'd learn. In Perl 6 I can "talk"; in other languages, I write "code".
However, while the language is fantastic, the implementation still has a lot of work to be done to polish it off. It's basically a 1.0 release. Unlike Go, Rust, or Swift, there isn't a giant corporation behind Perl 6 that can just throw money at problems until they disappear. Compared to other languages, some things are still unoptimized and are much slower. I spotted some leakage that makes it problematic for very-long-running (months) programs. About 65 new bug tickets are opened per month. The test suite is pretty sparse in some areas (which is the likely reason for many of the new bug tickets). But... three new core developers joined this January, so hopefully all that will get improved pretty fast.
Someone in the comments also mentioned the baby-sized ecosystem... Since Perl 6 lets you use C libraries without needing to compile anything, people wrote stuff like Inline::Perl5 and Inline::Python that let you import and even subclass stuff from Perl 5 and Python. And that's a bit of a double-edge sword: yes, it's trivial to use libraries from Perl 5 and Python, but it also stunts the ecosystem; no one has enough motivation to re-invent the wheel in Perl 6 when the wheels from other languages are reasonably usable.