On Tue, Nov 26, 2013 at 12:30 PM, Michael Montague <xxxxxx@gmail.com> wrote:
I propose to integrate PCREs by having the same API work for both. The grammer for SREs would be changed to require that they are lists. This would remove the ambiguity: strings are PCREs and lists are SREs.
There is no ambiguity - everything is an SRE. Your proposal
on the other hand introduces an ambiguity - strings are sometimes
PCREs and sometimes SREs.
This is arguably more convenient if you want your API to support
both PCREs and SREs interchangeably, and is in fact what IrRegex
does. But the ambiguity is dangerous, and simple SRE manipulations
become more complicated (e.g. the individual contents of a seq may
not in fact be SREs), so I chose to remove it in this SRFI.
There will be a separate SRFI that will introduce 3 bindings:
(sre->pcre <sre>)
(pcre->sre <string>)
(pcre <string>)
with the last being the PCRE syntactic equivalent of `rx'.
The compiled regular expressions will be the same type as
in this library, so you would use these as:
(regexp-search (pcre "a.*b") my-string)
although the exact details are outside the scope of this