@11, yes. But we're also talking about implementing backtracking, grouping, character matching, ranges, line delineation, escaping, character classes, subpatterns (named and unnamed), repetition, atomic grouping and possessive quantifiers, backreferences, assertions, conditional subpatterns, conditional matches ([0-9]|[a-zA-Z]), comments, recursive patterns... I could go on. And that's just some of the features that people would expect, and probably want, n a regular expression engine, and libraries like PCRE and PCRE2 already provide all of that. (It also provides subpatterns as subroutines, callouts, and backcontrol, and one other thing too.) There's no point whatsoever in writing your own regular expression parser in a language that doesn't provide one when there are libraris that are widely known (and that people will know how to use) rather than inventing your own syntax and attempting to implement all of that when people start requesting it, which they will do, very quickly. The quantifiers, especially, will be particularly important, unless you want to match [0-9]+ between five and a hundred times and enjoy writing that same range expression well over 200 times and making expressions that take five minutes just to read? Believe me, I know how painful that is, because MOO doesn't have quantifiers. One of my regular expressions, which is quite short in engines like PCRE, is over a thousand characters in MOO's regular expression engine.
"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." — Charles Babbage.
My Github