As a Haskeller, I don’t actually think this is valid. I think there is definite untapped potential for Ren-C to be better than Haskell, at least in one of these metrics.
Firstly: note that parser combinators were not always ‘blazing fast’. There was a time when they were considered almost unusably slow. As I’ve said, the Haskell community needed to find the right trade-offs to get the speed up to where it is now… and I’ve definitely met people who think those trade-offs aren’t worth it (even if I personally do).
But also: it’s worth thinking a little closely about how Haskell parser combinators get that ‘rigor’. In large part, they do it by building everything off a set of well-defined abstractions: Monad, Alternative, and so on. This gives a flexible and reliable toolkit for composing parsers together, from which flows many other advantages.
But this approach has some disadvantages as well. The most prominent is that these particular abstractions can be, in some sense, ‘too big’: they might give parsers capabilities you might not want. In this case, the main culprit is Monad, which gives parsers the ability to depend arbitrarily on the results of earlier parsers. On the one hand, this allows context-sensitive parsing — but on the other, it makes static analysis impossible.
By contrast, Rebol parsers are completely specified ahead of time. You can inspect at the BLOCK! which is passed to PARSE or UPARSE, and see ahead-of-time the entire control flow of the parser. That gives you the opportunity to do clever optimisations… such as, let’s say, precompiling the whole parser into an ultra-fast LR lookup table. Even in Haskell, many people prefer to use such parser generators over parser combinators, despite the clunkiness it adds — a parser generator embedded into the language itself would be pretty amazing to use.
You can think of more creative uses too, of course. For instance, the Red people have used this capability to generate railroad diagrams, another thing Haskell parser combinator libraries can’t do.
I’m not quite sure what you’re referring to here… but if I understand you correctly, this sounds equivalent in power to what the Monad interface gives you. Most parser combinator libraries will allow you to alter the parser on-the-fly in crazy ways, if you really want to do so.
This is another one of those tradeoffs. To support arbitrary backtracking in a parser combinator system, you need to store the text to backtrack over. You can just not store that text, but then you can’t do any backtracking (or in more technical terms, you’re restricted to LL(1) grammars). So this is another place where Rebol potentially has an advantage, since it can analyse the parser before running it.