You might think I am just talking about Microsoft's quirky implementation but even in the Linux-sphere it isn't consistent see:
http://www.greenend.org.uk/rjk/tech/regexp.html
You take a complex format string which was design to use the fewest characters instead of with clarity in mind, you then have every major application and library diverge on basic support and spec for features, and then you have all of them hack on support for UNICODE in their own unique way.
Regular Expressions likely won't ever die, but I for one would happily switch to an alternative with better readability, UNICODE support from day zero, and fewer niche features to keep things uniform. I'm tired of re-learning RegEx only to have everything I've learned either be forgot or not work the second I app switch.
The two main differences between various engines are which characters are "literal" and which characters are "magic" (Vim's engine is particularly annoying here), and how to write the "convenience character classes" (like what the shorthand for "alphanumeric character class" is). But these are minor issues, once you've learned how to write a regex, these are trivial to look up.
Knowledge of regular expressions transfer from one engine to another just fine.
You've already described a feature which has different syntax in one of the primary regex dialects I use (Emacs).
Most notably, the choice operator can either be ordered like in PEGs (if the first branch matches, the other isn't evaluated) or pick the branch that produces the longest match, CFG-like.
Learn those, or at least the main differences between them, and the vast majority of the regular expression engines in software you use will become more recognizable.
I'd agree with you if everything weren't so easy to look up.
https://stackoverflow.com/questions/1732348/regex-match-open...
^(\((?1)?\))$If you didn't know, a regexp engine with capture groups is already stronger than what in formal languages theory is called "regular expressions".
Also, you don't wanna spoon feed students, they'll never learn to fish. You would indeed have to go as far as implementing a regex engine or implementing I don't know, a certain finite automate in regex. I'm kidding but all you could realistically achieve would be the usage of a catalogue like command-line-fu or stackexchange unless the whole thing fits in a broader cs syllabus/curriculum.
[1] lrovocative statement: sed and awk are breaking the "do one function and it well" idea of unix.
You don't even have to be able to code to make use of regular expressions. You can use regular expressions when searching and replacing in editors (even slightly barebones editors like gedit or kate). You can transform input data from almost any format into any other format using nothing but your editor and a series of replace statements. (No computations though.)
I think they should teach regex in high school. Many people working in non-IT office jobs could benefit from knowing regex, and I think it's really quick to learn this. (Now if only Excel's/Word's search/replace supported regex...)