| You might be right about why Unicode was slow. In which case I was right. > So much so that to properly support Rakudo on Parrot would require a rewrite of [the middleware]. Which also means that most of the work you would have done to Parrot would needed to be reworked again afterwards. There was `ifdefs` all over the NQP and Rakudo codebases to work around Parrot's differences. Which was annoying and error-prone. The `ifdefs` are now mostly in NQP. And even those tend to be constrained a bit. --- > Rakudo's parser was (maybe still is) slow because it can't optimize anything, even the <ws> token. That is factually incorrect. There are several known optimizations that have not been implemented yet. One of which was even in STD. Also since Raku treats regexes as code, optimizations to regular code paths can also apply to regexes. That includes optimizations to calling methods like using the <ws> token. The main reason that they haven't been many is that the people that are competent enough and confident enough to do that work have been busy doing other things. Both their dayjobs and other optimizations or design work. Really as far as I know, there have been next to no attempts to optimize specifically regexes and grammars since they first got to the current feature set. Certainly not in the several years where I was looking over every commit to Rakudo. |