4 ms·

Flexible regex engines. Pattern matching is a much more general problem than string matching, and you don't necessarily always have the entire input available i

Flexible regex engines. Pattern matching is a much more general problem than string matching, and you don't necessarily always have the entire input available initially. (In fact, especially for performance reasons, you might the pattern itself to tell you what possibilities to consider for the next portion of your sequence.) I've repeatedly found that a regex engine that can work on more general objects (not necessarily string/numeric inputs) and which can be fed the input at the caller's convenience could be quite handy for some applications.

gfxgirl 6y ago
I just wish there were better UIs for much of this stuff. Most code editors have a regex search and replace figuring out the regex requires too much regex expertise. I can't think of a good example off the top of my head but for example, being able to search for things that match multiple rules. It would be much easier for many users to be able to say "starts with x", "ends with y", "has abc in the middle" as 3 separate statements than to have to derive the regex that does it. Similarly being able to search easily for balanced parens, brackets, quotes. And being able to search programming language aware as in "only in strings", "only in comments", etc... All of those seem like they'd be useful features but I know of no editor that do any more than just a single regex with no context
- gcmeplz 6y ago
  > It would be much easier for many users to be able to say "starts with x", "ends with y", "has abc in the middle" as 3 separate statements than to have to derive the regex that does it. This seems like a less error-prone and more testable way of writing regular expressions in code too! Writing out the individual portions of a regular expression might be a ton more verbose, but it's because regular expressions hide a ton of complexity with "write-only" shorthand.
aarroyoc 6y ago
Some of the things you say can already be achieved with Prolog DCGs, which are more or less like pattern matching over lists (usually lists of chars, but not needed).

gfxgirl 6y ago

I just wish there were better UIs for much of this stuff. Most code editors have a regex search and replace figuring out the regex requires too much regex expertise. I can't think of a good example off the top of my head but for example, being able to search for things that match multiple rules. It would be much easier for many users to be able to say "starts with x", "ends with y", "has abc in the middle" as 3 separate statements than to have to derive the regex that does it. Similarly being able to search easily for balanced parens, brackets, quotes. And being able to search programming language aware as in "only in strings", "only in comments", etc... All of those seem like they'd be useful features but I know of no editor that do any more than just a single regex with no context

gcmeplz 6y ago
> It would be much easier for many users to be able to say "starts with x", "ends with y", "has abc in the middle" as 3 separate statements than to have to derive the regex that does it. This seems like a less error-prone and more testable way of writing regular expressions in code too! Writing out the individual portions of a regular expression might be a ton more verbose, but it's because regular expressions hide a ton of complexity with "write-only" shorthand.

aarroyoc 6y ago

Some of the things you say can already be achieved with Prolog DCGs, which are more or less like pattern matching over lists (usually lists of chars, but not needed).