A human way to define regular expressions in Ruby

Am I the only person who thinks that things like this are totally unnecessary? Is learning&#x2F;reading regular expressions really that difficult for most people?<p>Here&#x27;s the subset of regular expressions that has gotten me through nearly all of the regular expressions I&#x27;ve ever needed to write. As a plus, it has no dependencies!<p>* - zero or more of the preceding character&#x2F;group<p>+ - one or more of the preceding character&#x2F;group<p>? - zero or one of the preceding character&#x2F;group<p>$ - end of line<p>^ - beginning of line<p>. - one of any one character<p>\ - escape the following character (for a literal &#x27;$&#x27; or &#x27;.&#x27;, for example)<p>[&lt;some characters&gt;] - one of the given characters<p>[a-zA-Z0-9] - letters and numbers inside a group can have ranges!<p>(&lt;something&gt;) - capturing group (anything that matches inside it will be accessible in the match object)<p>&lt;thing1&gt;|&lt;thing2&gt; - either the first thing, or the second thing (or the third, or the fourth...)<p>This isn&#x27;t a complete, or even precise, definition, but knowing those things will get you to the point where you can read and write expressions like this:<p>^(-|+)?[0-9]*\.[0-9]+$<p>which matches things like -.2, 0.123, +0.1, etc. (floating point numbers, basically). This likely has bugs, since I haven&#x27;t tested it ;)

I really don&#x27;t understand why some people are so afraid of regex. Sure, it&#x27;s not perfect, but these symbol-less solutions feel to me like one step forward and two steps back. A more interesting development would be something along the lines of what Perl 6 is trying to do (if only someone could implement it).[1]<p>We should start treating regex like a computer language in its own right, rather than some second-hand citizen that we stuff into a single line without any delimiting whitespace. Use the &#x2F;x switch and comment your code as you would with any other programming language, and you&#x27;ll find that regex really isn&#x27;t that scary.<p>Take the example pattern. The regex written by a human might look something like so:<p><pre><code> m{^ https? :&#x2F;&#x2F; # Protocol (?: \w+ \. )? # Subdomain ([\w\-]+) \. # Domain (?: com | org ) # TLD &#x2F;? $}x </code></pre> It&#x27;s certainly easier to parse. Debugging it is also a lot easier. We can see that this won&#x27;t match anything with more than one subdomain. We can also see that it won&#x27;t match subdomains that have hyphens in them. It also looks at a glance much more like a URL and less like some arbitrary Ruby code.<p>[1]: <a href="http://www.perl6.org/archive/doc/design/apo/A05.html" rel="nofollow">http:&#x2F;&#x2F;www.perl6.org&#x2F;archive&#x2F;doc&#x2F;design&#x2F;apo&#x2F;A05.html</a>

This is interesting. I find that regexes are one of the few places where a comment explaining what a block of code does is generally necessary. Since the &quot;ruby way&quot; is to use aggressively replace comments with method and variable names, a tool like this is a good way to achieve that goal.<p>That said, this also makes a huge tradeoff against conciseness. Personally, I&#x27;d prefer<p><pre><code> # Is foo a valid klingon email address? foo =~ &#x2F;gibberish&#x2F; </code></pre> Over<p><pre><code> foo = Hexpress.new. start(&#x27;g&#x27;). maybe(&#x27;i&#x27;). many(&#x27;b&#x27;). find(&#x27;b&#x27;). ...</code></pre>

Please yes!<p>I did a little research and this derives from Verbal Expressions, as explained [1] and implemented [2]. In any case, I&#x27;m emphatically in favor. I&#x27;m the sort of programmer that needs to write maybe one regex per month, and I&#x27;m tired as hell of relearning the human-meaningless syntax for regexs, let alone all the little variations between languages. Not to mention, if it can vastly reduce the number of symbols I have to escape when matching special symbols, so much the better.<p>[1] <a href="http://thechangelog.com/stop-writing-regular-expressions-express-them-with-verbal-expressions/" rel="nofollow">http:&#x2F;&#x2F;thechangelog.com&#x2F;stop-writing-regular-expressions-exp...</a> [2] <a href="http://verbalexpressions.github.io/" rel="nofollow">http:&#x2F;&#x2F;verbalexpressions.github.io&#x2F;</a>

Wow. My mind is blown.<p>It almost feels like what high level programming languages are to assembly code.<p>Sure, we can (and should) learn Regex constructs, but it is undeniable that this library provides an unmatched level of clarity.<p>Kudos to Krain for coming up with such an elegant solution to the issue of Regex building&#x2F;reading.

Regular expressions were very invented to avoid this. Because this works fine only as long your regular expressions are small and few.<p>Once that fact changes you will find yourself writing and staring at walls of text.<p>You will do this enough number of times, then only hope that you have a more succinct and powerful way of expressing such a idiom, you will do all that only to realize using regular expressions are the only way to solving a range problems which it was designed to solve.<p>The easiest analogy I can give you math. Prior to manipulation of symbols, math was pretty much text. The whole of math looked paragraphs of puzzles and word play. Worked fine when you want to do small things like postulates, axioms and a few things derived from that. To move a higher level of abstraction and interplay of concepts we had to get into symbols.<p>This is something similar.

Python&#x27;s re.VERBOSE let you write [1]<p><pre><code> a = re.compile(r&quot;&quot;&quot;\d + # the integral part \. # the decimal point \d * # some fractional digits&quot;&quot;&quot;, re.X) </code></pre> Instead of<p><pre><code> a = re.compile(r&quot;\d+\.\d*&quot;) </code></pre> But that is as far as it goes for me. From that point, masking REGEX with additional layer of 10&#x27;s of functions is not a wise move.<p>[1] <a href="http://docs.python.org/2/library/re.html#re.VERBOSE" rel="nofollow">http:&#x2F;&#x2F;docs.python.org&#x2F;2&#x2F;library&#x2F;re.html#re.VERBOSE</a>

This completely illustrates what I hate most about ruby: the conflation of &#x27;understandable code&#x27; with some sort of insane directive to turn everything into an English sentence without any regard for what the code actually does. At its worst it&#x27;s almost an obsession with enforcing technical ignorance.<p>That said, regexes can be tricky to parse and making them clearer to the average person is a worthy goal.

I don&#x27;t understand why so much hate for the library. For me, this is a very ruby way to tackle regular expression problem that newbie like me have.<p>Not that I&#x27;m saying that newbie shouldn&#x27;t learn regex. But any level of abstraction would be great. Rails abstract the complexity of web development. Hexpress abstract the complexity of regex. Both are win in my book.

Like VerbalExpressions, this a good idea carried out without full acknowledgement of the nature of regular expressions. There&#x27;s no shortcut - concatenation, union, and kleene star. A URL operator doesn&#x27;t replace any of them.<p>If there isn&#x27;t isomorphism between the traditional symbols and the new names, then the expressions will be limited in expressiveness.

Here the same[1]. This library squats vocabulary in a bad way. e.g.:<p>#word is (\w+). This works in english, but breaks very early. Still, it might be correct in some time. &quot;word&quot; is extremely context-sensitive.<p>[1] <a href="https://news.ycombinator.com/item?id=6319584" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=6319584</a>

It seems like the argument against regexes is that they can get really complex and unreadable. For something as simple as that url, isn&#x27;t it easier to just use a regex?<p>Seems like in the &#x27;unreadable&#x27; regex case, you&#x27;ll have a boatload of verbose function calls to construct it.

So as computer scientists, we&#x27;re in the business of tradeoffs right. I think the conciseness tradeoff for clarity is good. Abstracting away from pure regular expression syntax is a good thing, I think, because it offers better AT A GLANCE reading.<p>Why would that be better? I recently saw Bret Victor&#x27;s Inventing on Principle talk on Vimeo, and one of the things he mentions that I really agree with is that most of us must &#x27;think like computers&#x27; to understand what our code will do. The less we have to do this, the better, because we&#x27;re terrible computers<p>Now am I likely to use something like this? No, mostly because I don&#x27;t program in ruby TOO often, and I am pretty well aware of how to use regular expressions.

Here&#x27;s a link to the VerbalExpressions organization that contains implementations of a similar DSL for various languages: <a href="https://github.com/verbalexpressions" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;verbalexpressions</a>

Cute, but I prefer just using Rubular to test out regex&#x27;s

Or instead of learning start maybe with words multiple has either ending you learn ^?\w+(|)$.<p>I&#x27;d imagine that wrappers such as this one do not enable users to create any more complex patterns, than ones they could make with a most basic understanding of regular expressions. Whilst providing neither a base for more complex regex use nor a community to further an understanding of regex.

Now we need a human way to write Ruby in Python.

The reason that this library is useful is because I don&#x27;t have to maintain an AST in my own feeble mind about what each special character in the regex means. I can look at the code, at first glance, and immediately know what the hell is going on.<p>Also, this.<p><a href="https://xkcd.com/208/" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;208&#x2F;</a>

Library owner here, I&#x27;ve added some replies to points made but I just want to note that the readme on Github&#x27;s website was a bit out of date and provides a little more details now.

Seems easier to just use a regex. Every programmer should know them already, so this is just another API to remember. Still kinda cool though, but prob not so useful.