[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: benefits of SRE syntax

This page is part of the web mail archives of SRFI 115 from before July 7th, 2015. The new archives for SRFI 115 contain all messages, not just those from before July 7th, 2015.



On Wed, Oct 16, 2013 at 2:44 PM, Michael Montague <mikemon@xxxxxxxxx> 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.

In general, it seems to me the big benefit is clarity. Traditional RE string syntax has a high floor to understandability, and even experts have to parse out complicated ones into subparts to get them. Why not present the parts independently and optionally document them?

-Roderic