Stop writing Regular Expressions. Express them with Verbal Expressions.

Stop writing Regular Expressions. Express them with Verbal Expressions. by Jerod Santo.

From the post:

GitHub user jehna has fashioned a runaway hit with his unique way of constructing difficult regular expressions.

VerbalExpressions turns the often-obscure-and-tricky-to-type regular expression operators into descriptive, chainable functions. The result of this is quite astounding. Here’s the example URL tester from the README:

// Create an example of how to test for correctly formed URLs
var tester = VerEx()
            .startOfLine()
            .then( "http" )
            .maybe( "s" )
            .then( "://" )
            .maybe( "www." )
            .anythingBut( " " )
            .endOfLine();

You can think of other regex languages that are more concise, but can you think of one as easy to teach to new users?

I think there is a lesson here for hand editing of topic maps.

Such as discovering what commons terms particular people would use for topic map constructs.

Those terms could become their topic map authoring language, with a translation script that casts their expression into some briefer notation.

Yes?

3 Responses to “Stop writing Regular Expressions. Express them with Verbal Expressions.”

  1. clemp says:

    Sounds like a great idea but wouldn’t casting something into a briefer language mean the user is still working at the lowest semantic level just using a different vocabulary: like assembly code instead of machine language? Maybe the Domain Specific Language could be at a higher level of abstraction so that is could be expanded into multiple constructs that represent higher level structures: like the Topic map equivalent of C, Python, or SQL.

    However, the first step would be to create a catalog of common topic map structures or patterns. It seems like such a catalog could eventually enable automated or computer assisted construction of topic maps to supplement hand-editing of topic maps. Hand-editing is a necessary first step but it does not scale well. Imagine how few applications there would be now if everything had to be coded in assembler. Or how few databases would there be now if everyone had to build their own out of B-Trees.

  2. Patrick Durusau says:

    I was thinking more along the lines of higher level languages, DSL for sure.

    Think of it as being like auto-completion. When a lawyer says, “…the party of the first part,” an association is created with a topic for the party of the first part and as other players are named, they are added to the association. Roles could be composed of their obligations in the contract (we say seller/buyer as a shorthand for those). All the parts of a number of transactions, mortgages for example, are fairly well known. And there are a lot of them.

    That’s not the unconstrained authoring case but I think the unconstrained case is vastly overrated. There is a lot of mileage in fairly routine and constrained cases.

    +1! on hand editing. I think we need assistive interfaces suggest solutions and/or provide information to allow you to do the hard cases.

  3. clemp says:

    That sounds like a great idea. I agree about unconstrained authoring. The flexibility is great for experts but it usually comes at the cost of making it harder to do the routine things that I’d prefer to let the computer do for me.