Which means that this CAN NOT BE USED TO ACCEPT REGULAR LANGUAGES. The language (a|b)*, any number of as or bs in any order, can not be descibed using that parser.

"considerable simplification" sounds like it's kinda regex. It's not even basic regular expressions/regular languages.

Edit: The author reimplements code from https://www.cs.princeton.edu/courses/archive/spr09/cos333/be... which acknowledges that the implemented subset does not match all classes but they propose that the classes they can parse, are already useful. The author of the new article makes no such acknowledgement that their implementation just represents a subset of regular languages.

Of course, the regular languages themselves are also just a subset of regexp, which can match more languages due to constructs like references.

I really hated that Lua's "pattern" [1] is never a regular expression nor a regular language. So annoying that it will be better not to have it.

[1] https://www.lua.org/manual/5.3/manual.html#6.4.1

Lua is not a language to be used as is (and it isn’t in practice). Simple pattern matches are there for internal needs like constructing package paths, but one can luarocks install any regex implementation at will.

Bad side is that luarocks works fine on Windows only if no build step is involved, otherwise you’re doomed to mess with mingw/msys/msys2 environment that isn’t well-supported by third-parties; often not supported at all. It is not Lua’s fail, but it happens. New complicated build systems like CMake only make things worse since you cannot simply guess flags and gcc .c together anymore.

Edit: this is also true for all languages except maybe perl that includes full mingw system with it. Idk why some package managers do not prebuild windows packages on server-side. Windows actually does a lot to maintain binary compatibility.

In Lua, LPeg[1] is my goto for anything that can't be done/gets too complex with patterns.

[1] http://www.inf.puc-rio.br/~roberto/lpeg/