This is the kind of stuff that makes (some) people hate programming =P

It is also the sort of thing I’ll likely remember for the rest of my life, unlike other less important information, like bank accounts, government ids, phone numbers, people’s names, etc.

I don’t understand. Nowadays people don’t remember their ASCII by heart any more?

This is just the type of coffee time reading that I enjoy. A beautiful discovery, must have been very satisfying.

I read this as ‘Any character between ‘,’ and ‘.’ in ASCII, and wondered if the surprise was that ‘.’ comes before ‘,’ and somehow matching now happens between ‘.’ and the last character, and also ASCII 0 and ‘,’

To me then, it does what I expected, but the surprise was that the three characters are at those particular positions. The author’s surprise was different. I think this just adds more evidence that regular expressions are surprising.

That said, they are still the best tool for some jobs and I will use them, laid out over multiple lines and commented, and not shared with others, because the worst problem with regular expressions is that you can’t trust that everyone will read them the same, including your future self.

Reminds me of some IRC daemons doing case-insensitive comparisons for special characters and therefore treating nicknames like abcde|{} to be the same as ABCDE\[]. It’s indeed a property of the ASCII table and an XOR with 0x20 will flip those characters from one case to the other.

Yup, ascii(7) manual page is very useful for this type of info. Also if one needs to %-encode a character, i.e. in a URI, etc.

With Egg expresssions, you must quote characters that aren’t alphanumeric, so the difference between literals and operators is clear.

oil$ const pat = / [',' - '.'] /
oil$ = pat
(Regex)   [,-.]

(The = operator shows the value of an expression, which in the regex case is the ERE it compiles to.)

oil$ const pat = / [ - '.'] /
  const pat = / [ - '.'] /
                  ^
[ interactive ]:8: Syntax error in expression (near Id.Arith_Minus)

So if you quoted that, then it would work. The same applies outside character classes – CODE and DATA are distinct! This is a big problem with both shell and regex syntax.

Egg expressions are also statically parsed like code, not dynamically parsed like data.

In the sport of fencing, there’s an aesthetic concept carried over from its dueling roots known as la belle mort (the beautiful death) wherein two opponents match each other touch for touch with increasingly complex attacks until, tied and exhausted, they are one touch away from the end of the bout. One of them brings the tactical wheel back around to a simple attack and the other, like being knocked over with a feather, fails to anticipate it and loses. In a real duel, it would be considered even more beautiful if both opponents died from their wounds.

This is all very weirdly romanticized and morbid, much in the way that death by Perl regex seems to be from some of the applause here. Somehow the author has tricked themselves into spotting a mistake only to find that their limited knowledge of character order in the Unicode table (and I do believe it’s Unicode, not ASCII) made the mistake one of their own misinterpretation.

At the risk of moralizing, the lesson should not be (in effect): Someone’s regular expression confused me, which is their fault, so I will rewrite it in a way that makes more sense to me and preemptively tell you all to write regular expressions the same way.

Instead, it should be something more like: Humans are too fallible to understand regular expression reliably without aids. Anyone who implies that there’s anything obvious about regular expression syntax is either lying or deluded. I was deluded. I will therefore use diagram tools when I have to read or write regular expressions (there have been several over the years) and will generally prefer parsers or codecs, which are generally more deliberate and less ambiguous.

python’s regex module has a re.VERBOSE flag which ignores (most) whitespace and allows comments. and python strings (and regexes) allow for ‘named characters’ using the \N{...} syntax.

combining the two can massively help regex writing/maintenance. the \d{2}[,-.]\d{2} example from the article can be written like this, for example:

import re
pattern = re.compile(
    r"""
    \d{2}
    [\N{comma}\N{hyphen-minus}\N{full stop}]  # separator
    \d{2}
    """,
    re.VERBOSE
)
print(pattern.fullmatch('12.34'))
# <re.Match object; span=(0, 5), match='12.34'>

whitespace is not ignored inside character classes [...] so these three cannot be split over multiple lines. a (non-capturing) group with parentheses can be used instead though:

pattern = re.compile(
    r"""
    \d{2}
    (:?  # separator
        \N{comma}
        | \N{hyphen-minus}
        | \N{full stop}
    )
    \d{2}
    """,
    re.VERBOSE
)

while this may not be the best example since it gets rather verbose for something that started out as something relatively simple, for more complex regular expressions this can be the difference between ‘write once’ and ‘actually maintainable’.

cursed regex

Task failed successfully.

or

You arrived at the right answer by the wrong method.

I never imagined a regex can make developers smile.

Wouldn’t this be slightly faster in a naive implementation? Two compares instead of three…