Compile-time checks for Regular Expressions

milesfrain · June 17, 2020, 8:48pm

Could regular expressions be checked at compile time, rather than relying on unsafePartial when calling regex?

It’s a bummer to instruct readers to write “unsafe” code in Ch7 of the book, and likewise tedious to account for the Left error during runtime.

Is something like C++`s constexpr available?

paluh · June 17, 2020, 9:02pm

Recently I’ve seen this package by @sharkdp :

I have not used it yet and I’m not sure how “regexp safe” the above DSL is (if it is feasible to construct a “bad” regex with it) but it looks really nice in action:

github.com

VerbalExpressions/purescript-verbal-expressions/blob/master/test/Main.purs#L18


import Test.Unit as Unit
import Test.Unit.Main (runTest)
import Test.Unit.Assert (assert, assertFalse, equal)

import Data.String.VerEx (VerEx, VerExMatch, digit, upper, lower, capture,
                          find, match, endOfLine, some, possibly, startOfLine,
                          exactly, replaceWith, anythingBut, replace, insert,
                          word, whitespace, test, findAgain, withAnyCase, tab,
                          lineBreak, many, anyOf, something, anything)

url :: VerExMatch
url = do
  startOfLine
  protocol <- capture do
    find "http"
    possibly $ find "s"
  find "://"
  domain <- capture do
    possibly $ find "www."
    anythingBut " "
  endOfLine

milesfrain · June 17, 2020, 9:08pm

verbal-expressions initially seemed like the solution, but has some blocking limitations.

paluh · June 17, 2020, 10:15pm

Good to know. Thanks! Maybe we should try to solve these limitations as this lib is also an interesting piece / example of a DSL construction in PS.

P.S.
To be honest I sometimes use unsafeRegex when building a Regex. I use this construct on the top module level so it blows up really quickly (please check the console) during a first run (nearly the “compile time” :-P).
Maybe showing to the reader that not everything can be easily proven to be type safe has a value on its own. I think that is is good to be aware that it is really easy to leave the safe PS land and fallback into the ugly unsafe solution when it is necessary. It is also an opportunity to answer the question why we have something like unsafeRegex in the given lib at all and how to use such a tool to minimize a possible damage.