4 ms·

It's concise. Regexps can be documented and split onto multiple lines in many languages and commented, be it through string concatenation or formatting modifie

It's concise. Regexps can be documented and split onto multiple lines in many languages and commented, be it through string concatenation or formatting modifiers. I write some complicated regular expressions, and I've found that splitting groups of expressions onto multiple lines and indenting them handles most of the problems that my coworkers have with groking them, and that I have when returning to them. I prefer the concise syntax (provided that it's reasonably formatted) for the same reason that I prefer the concise syntax of sed, ed, and similar: it's easy to mentally map and reason about symbols than it is large blocks of text. I've been programming for nearly 20 years and I have found that I much prefer manipulating mathematical expressions than I do large chunks of code, because it uses a concise syntax where symbols mean something. I love such a notation. (In the case of programs, when refactoring, my mind works in blocks of code as units, as I'm sure most others' do.) I'm not saying those benefits aren't possible with verbose code---they are. But just as many prefer a concise mathematical syntax to a verbose program that does the same thing, I prefer a concise formal definition. I'm also not implying that you should try to write an entire grammar in a single regular expression.

junke 10y ago
Concise notations are great, and this is why regexp are so much used IMO. I am by the way a fan of sed, which is clever enough to give you the choice over the delimiter you use (s+/+_+g). On the other hand, there are so many additions to the core formal language, like backtracking or Larry Wall knows what, that syntax has become cryptic. Besides, building regexps out of smaller ones is generally a pain with strings, because you need to quote special regex characters, along with any character that might interfere with the host language's syntax (e.g. emacs regexes with four backslashes in a row). I prefer to read actual words, so the following is fine for me: (defvar *email-regex* '(:sequence :word-boundary ;; IDENTIFIER PART (:regex "[A-Z0-9._%+-]+") #\@ ;; DOMAIN (:regex "[A-Z0-9.-]+") #\. ;; TOP-LEVEL DOMAIN (:greedy-repetition 2 nil (:char-class (:range #\A #\Z))) :word-boundary)) After the recent discussions about Lisp, here is an actual example that can be used by CL-PPCRE to scan "\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b". The list structure allows you to compose your regular expression like any other list, with intermediate functions, etc. without having ever to thing about escaping your characters. When you need to use the string based, concise regex, you wrap it in a ":regex" form and you have the best of both worlds.
- mikegerwitz 10y ago
  > On the other hand, there are so many additions to the core formal language, like backtracking or Larry Wall knows what, that syntax has become cryptic. I'm not going to argue with that, though languages like Perl (which have extended regular expressions so much that they're not actually regular expressions anymore) also allow named groups, for example. I'm not arguing that certain circumstances aren't difficult to understand. In such cases, I do actually compose expressions from separate ones (e.g. variables): but they're still a concise syntax. > (e.g. emacs regexes with four backslashes in a row). Yes, such cases are unfortunate and confusing. > I prefer to read actual words, so the following is fine for me: For me, that took much longer to parse mentally than the equivalent regex. Or, if you're okay with minor changes and a proper locale: /\b[\w.%+-]+@[\w\d.-]+\.[A-Z]{2,}\b/ I suspect that someone used to reading the notation you provided would have opposite results than I do. The reason I find the actual formal notation for the regex easier is because there's less to keep in memory---all the verbose extras that I have to strip out when forming my mental image of the regex. If the regular expression were more complicated, the solution you presented might not be so bad. I would normally format it like this (if we stick with the verbose character classes): /\b [A-Z0-9._%+-]+ @ [A-Z0-9._-]+ \. [A-Z]{2,} \b /
  - mikegerwitz 10y ago
    Ah, that didn't format well at all. I intended for this to display: / \b [A-Z0-9._%+-]+ @ [A-Z0-9._-]+ \. [A-Z]{2,} \b /

junke 10y ago

Concise notations are great, and this is why regexp are so much used IMO. I am by the way a fan of sed, which is clever enough to give you the choice over the delimiter you use (s+/+_+g). On the other hand, there are so many additions to the core formal language, like backtracking or Larry Wall knows what, that syntax has become cryptic. Besides, building regexps out of smaller ones is generally a pain with strings, because you need to quote special regex characters, along with any character that might interfere with the host language's syntax (e.g. emacs regexes with four backslashes in a row). I prefer to read actual words, so the following is fine for me: (defvar *email-regex* '(:sequence :word-boundary ;; IDENTIFIER PART (:regex "[A-Z0-9._%+-]+") #\@ ;; DOMAIN (:regex "[A-Z0-9.-]+") #\. ;; TOP-LEVEL DOMAIN (:greedy-repetition 2 nil (:char-class (:range #\A #\Z))) :word-boundary)) After the recent discussions about Lisp, here is an actual example that can be used by CL-PPCRE to scan "\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b". The list structure allows you to compose your regular expression like any other list, with intermediate functions, etc. without having ever to thing about escaping your characters. When you need to use the string based, concise regex, you wrap it in a ":regex" form and you have the best of both worlds.

mikegerwitz 10y ago
> On the other hand, there are so many additions to the core formal language, like backtracking or Larry Wall knows what, that syntax has become cryptic. I'm not going to argue with that, though languages like Perl (which have extended regular expressions so much that they're not actually regular expressions anymore) also allow named groups, for example. I'm not arguing that certain circumstances aren't difficult to understand. In such cases, I do actually compose expressions from separate ones (e.g. variables): but they're still a concise syntax. > (e.g. emacs regexes with four backslashes in a row). Yes, such cases are unfortunate and confusing. > I prefer to read actual words, so the following is fine for me: For me, that took much longer to parse mentally than the equivalent regex. Or, if you're okay with minor changes and a proper locale: /\b[\w.%+-]+@[\w\d.-]+\.[A-Z]{2,}\b/ I suspect that someone used to reading the notation you provided would have opposite results than I do. The reason I find the actual formal notation for the regex easier is because there's less to keep in memory---all the verbose extras that I have to strip out when forming my mental image of the regex. If the regular expression were more complicated, the solution you presented might not be so bad. I would normally format it like this (if we stick with the verbose character classes): /\b [A-Z0-9._%+-]+ @ [A-Z0-9._-]+ \. [A-Z]{2,} \b /
- mikegerwitz 10y ago
  Ah, that didn't format well at all. I intended for this to display: / \b [A-Z0-9._%+-]+ @ [A-Z0-9._-]+ \. [A-Z]{2,} \b /