Speak for yourself, this is a lot clearer for me. I'm used to navigating grammars, but I can't deal with regex (way too terse). Especially when I'm not just matching, but I want to extract info. Some verbosity can go a long way to making things clearer.
Don't know if this is the solution I'm looking for though
If the terse run-together-ness of usual regexes is unclear, you may also want to look into 'freespace' formatting... which lets you insert insignificant whitespace to break the regex into logical groups/lines, and even add inline comments:
I had never heard of this before.
The stated goal is to simplify difficult regular expressions, but the examples seem to be more complicated than the corresponding regexes. Maybe I'm just old school.
I'm not sure that someone who relies on this would be able to debug the resulting generated regex when something doesn't work as expected.
I agree that for someone who already has the skills to reason with regexes this has little to offer. But I'm not ready to count the idea out yet -- it's easy to underestimate the length to which people will go to avoid being forced to learn a new way to think. Easy string matching without regexes would have been extremely appealing to my just-starting-programming self.
As a language, Regex is somewhat opaque to most people these days.
Or a person wants to solve a simple problem by matching a simple string, so they decide to learn Regex. Now they have two problems, the second is learning to express what they want to do.
The problem this solves is casual use by people who don't match strings all day. There are tradeoffs - most of them are keystrokes. On the other hand for casual Regexers slowing down and unpacking the expression is probably useful.
I'm always a bit wary of posts that tell me to "Stop doing X". I'm also pretty comfortable with regular expressions. They take you outside of the procedural comfort zone, but are a valuable tool that will pay off to learn.
Still, it's worth a shot trying to create a tool like this. What I don't get is how they would handle subexpressions.
Looking at the wiki, I don't think it does handle them. I reckon that if jehna when to the trouble of making this, he knows of at least one use case, even if it's his own. I appreciate that he's shared his work. That said, from my own experience, by the time a regular expression becomes difficult for me to parse, there are subexpressions, negative lookbehinds, and other less comprehensible regex features that this library doesn't seem to support.
My first thought was that "Verbal Expressions" are simply parser combinators, which of course can do things that individual regular expressions can't do. From the examples though it looks like this is just translating to regular expressions under the hood, which would make it considerably less powerful than Parsec and other parser combinator libs.
