ReX.js – Your RegEx companion

    // match something that looks like a date in the form 02-14-1924
    let x = "";
    x += '\d{2}'; // match the month 
    x += '\-';
    x += '\d{2}'; // match the day
    x += '\-';
    x += '\d{4}'; // match the year

If a (dynamically built) regex misbehaves, I'm only inspecting the lines of code that compose the string, not an entire library to understand what went wrong.

Named captures can be created with the following helper (with an example that parses strings):

    import {avoid, capture, either, sequence, suffix} from 'compose-regexp'

    function makeNamedCaptures(indices) {
      let i = 1
      return function namedCapture(name, exp) {
        if (indices.hasOwnProperty(name)) {
          throw new Error("\"" + name + "\" is already used as a capture name")
        }
        indices[name] = i ++
        return capture(exp)
      }
    }

    const captureIndices = {}, namedCapture = makeNamedCaptures(captureIndices)

    const zeroPlus = suffix('*')
    const any = /[\s\S]/
    const anyNonReturn = /./

    const stringMatcher = sequence(
      namedCapture("quote", /['"]/),
      zeroPlus(
        avoid(ref(captureIndices.quote)),
        either(
          sequence('\\', any),
          anyNonReturn
        )
      ),
      ref(captureIndices.quote)
    )


    // stringMatcher is actually a plain regexp:
    console.log(`"foo'\\"'bar"baz`.match(stringMatcher))
    // --> [ '"foo\'\\"\'bar"', '"', index: 0, input: '"foo\'\\"\'bar"baz' ]

For complex grammar with sub-parts, you can wrap the sb-patterns in functions and inject the `namedCapture` as a parameter.

https://flems.io/#0=N4IgZglgNgpgziAXAbVAOwIYFsZJAOgAsAXLKEAG...

----

Regex syntax sucks, or more exactly, it look like is the bytecode for programming language that is left as exercise to the reader.

Maybe for the purpose of a more interesting discussion, let's just assume everybody knows (how to look up the docs for) regular expressions, but sometimes they're still lazy or just feeling playful, and want to do the same stuff with a different syntax... and this is just one first prototype of how maybe to do that. No offense intended, no claim that this will supersede learning regular expressions implied.

Case in point: logfile analysis. Often times you might have a log file with many different kinds of messages formatted in many different ways, only some of which you care about. A quick regular expression can pull out the messages of interest, and extract out the bits you care about. Sure, in an ideal world you'd ingest the logging data in some structured format, but the real world simply does not hand you the luxury of controlling all your upstream data sources all the time.

Sure, but I don't think the existence of this lib implies the author disputes that, and I can only imagine they're pretty familiar with regex themselves. I think they're trying to fill a legitimate need in frontend dev, which is: if you're only touching regex a few times a year, it's pretty intimidating, and not at all maintainable. SQL can also be difficult to grok if you don't write it often, and ORM interfaces make it easier.

Would the world be a better place if everybody knew regex perfectly? Yeah ok it would, but investing a bunch of time learning something you will only occasionally use is a poor investment IMO.

> If you don't, then go back to designing* I guess, and ask for a programmers' help

This seems to be needlessly condescending? You can be an excellent programmer (particularly in frontend) for years while avoiding regex. It's not a make-or-break thing.

Are you writing APL? Why not?

They are pretty much write-only, and there's no way to compose two regexps safely (new `RegExp(a.source, b.source)` breaks for `/a|A/, /b/, for example).

Rex is a good attempt at solving this. I wrote a similar lib a while ago (more functional and tighter in design, see my other comment on this page).

What if it was all on one line and his variable names were all "v1", "v2", etc. Would you help him then? fuck no. And yet, this is standard operating procedure with regex, except you don't even get "v1", "v2" because nothing is labeled at all. v1/v2/... would be an improvement!

This is how most people write a simple date regex:

\d{1,2}/\d{1,2}/(\d{4}|\d{2})

And mind you, this is a very simple scenario. Here is how you would write it if you treated it like actual code:

(?<month>\d{1,2})

/

(?<day>\d{1,2})

/

(?<year>\d{4}|\d{2})

First off, you can know what my intent is when I'm capturing each group. Maybe this code gets used by a european where the month and day switch places. They can figure out how to fix it in like two seconds. Secondly, the forward slashes are not lost in a sea of characters anymore because we use whitespace like a civilized developer, not a regex savage.

Was this actually necessary to say? It's not only insulting to people who don't need/care about/currently know regex, while simultaneously insulting of designers' intelligence.

But I gotta say, regex isn't the best way to show things. Hard to verify, hard to maintain and what not. Computer sciency, sure. But not well "designed".

Now I have no love lost for people who talk about stuff without understanding the fundamentals or the basics even. So I don't doubt that the person was "whatever". But I do feel that regexes need an overhaul

Ps: I'm a fan too when I have to do quick stuff in shell. But not so much when I save it to a file to be read by me and multiple people weeks later. Regex is one thing that is way easier to write than read.