[noprompt]

This isn't something I would recommend using for everyone. But it does have use cases that make it appealing and useful. The same thing could be said about VerbalExpressions.

While it's true `[:alpha:]|[:lower:]` (even better `([:alpha:]|[:lower:])` or just `[:alpha:]`) would work to match "foo", "bar", "baz", etc.; it would also match "turduken" or epsilon (""). This isn't always what you want.

One nice thing about generating a regular expression in this manor, is it's arguably much easier to maintain. Instead of having a heavy pattern to refactor or, god help you, append to, you simply add another string to your list and be on your way. Plus you get the potential memory savings and performance benefits.

In the case of VerbalExpressions, the `or` method could use the same technique as frak to improve the quality of the expressions it emits. While on the subject, VerbalExpressions could also borrow some good ideas from is Christophe Grand's regex library: https://github.com/cgrand/regex.

Edit: Forgot some colons.

[brudgers]

I don't disagree with any of your points. But I don't think they address the problem inherent in Frak - there's no way to insure that the expression gives the intended result against an arbitrary input.

The results with "barber" are indeterminate since the input string "bar" matches (^bar$) as well as (bar). In other who knows what language is described by the output of Frak?

I am not in love with VerbalExpressions - porting it to Racket was a reasonably sized project from which I felt I could learn something about Racket, I did. And something about regular expressions, which I also did.

I think VerbalExpressions suffers from a bit of the same conceptual problem as Frak - though perhaps to a lesser degree. That problem is treating Regular Expressions as something other than the formal description of a language.

However, I think that the transition from a muddled concept of regular expressions to correct one is more straight forward with VE - i.e. adding (kleeneStar), (atLeastOne), and (exactlyOne) to VE doesn't break the bigger idea.

The general problem with anything that attempts to implement regular expressions informally can be summed up as:

  Pick any two:
   
   ()Kleene Star

   ()Union

   ()Concatenation

It's a "cheap, fast, correct" problem.

[noprompt]

> "But I don't think they address the problem inherent in Frak - there's no way to insure that the expression gives the intended result against an arbitrary input."

I've made sure to thoroughly test the patterns produced by frak. They've also passed muster with another project where frak has proven to be a good idea (see this issue https://github.com/guns/vim-clojure-static/pull/28). While they are not full optimized (yet), I'm fairly sure they are correct. If you have found a counter example, please open an issue.

> "The results with "barber" are indeterminate since the input string "bar" matches (^bar$) as well as (bar)."

The next point release will allow users to specify an exact match. Initially, this wasn't an option because Clojure has two functions `re-find` and `re-match` for relaxed and strict matches respectively.

  user> (re-find #"bar" "barber")
  "bar"
  user> (re-find #"^bar$" "barber")
  nil

> "I think VerbalExpressions suffers from a bit of the same conceptual problem as Frak - though perhaps to a lesser degree."

There is nothing conceptually wrong with what VerbalExpressions or frak attempt to do. They may not provide value to everyone, but they are useful contributions and have tangible benefits.

> "That problem is treating Regular Expressions as something other than the formal description of a language."

Why is that a problem?

It has been shown it's possible to use regular expressions as a means to perform arithmetic. Is that too a problem?

I don't think so.

Formality is a great thing and necessary. But it can also be the opposite. While I'll agree understanding it is important, I'll contend getting hung up on it is dangerous.