On Thu, Oct 17, 2013 at 4:22 AM, Roderic Morris <xxxxxx@gmail.com> wrote:
On Wed, Oct 16, 2013 at 2:44 PM, Michael Montague <xxxxxx@gmail.com> wrote:
On benefit (1): they are more verbose, and readability is subjective. They will look different to anyone who has already learned the traditional syntax of regular expressions.

There are subjective elements to readability, but is not entirely so. We can convey more with code in general than the traditional syntax (which is meant to be line based and contained in strings) allow. SREs allow the structure of the code to convey information about the regular expressions they represent. Subparts of a compound expression can be presented on separate lines and commented, etc. It feels like moving from line editing to screen editing.
 
Another benefit to SRE, at least as they're implemented scsh, is the interpolation of scheme values into larger SREs. SREs can be created independently and combined. They can be combined with program input (with all the power and danger of that). These things can be more clearly written than they could be with the traditional RE strings, where you'd be concating strings or using a language's string interpolation facilities (which might not map 100% to a consistent RE interpolation). I haven't had time to look at the full srfi document to see if this feature or something like it has been preserved.

Yes, you can compose by splicing in other SREs (and char-sets).
This is slightly different from SCSH which allows splicing in
compiled regexps:

  SCSH: (let ((x (rx any))) (rx ,x))
  SRFI 115: (let ((x 'any)) (rx ,x))

The intention is to focus on the serializability and
ease of procedural generation of SREs.

There is one open issue which is whether to provide a
`regexp->sre' utility to retrieve the SRE from which a regexp
was compiled.  If we include this, we can also allow splicing
in compiled regexps in addition to SREs.

-- 
Alex