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.
I propose changing 'regexp' to 'sre-regexp' for future consistency with 'pcre-regexp'.
I propose changing 'rx' to 'sre' for future consistency with 'pcre'.
Why do SREs and PCREs need to convert back and forth between each other?
On 11/26/2013 4:42 AM, Alex Shinn wrote:
On Tue, Nov 26, 2013 at 12:30 PM, Michael Montague <mikemon@xxxxxxxxx> 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 proposalon the other hand introduces an ambiguity - strings are sometimesPCREs and sometimes SREs.
This is arguably more convenient if you want your API to supportboth PCREs and SREs interchangeably, and is in fact what IrRegexdoes. But the ambiguity is dangerous, and simple SRE manipulationsbecome more complicated (e.g. the individual contents of a seq maynot 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 asin this library, so you would use these as:
(regexp-search (pcre "a.*b") my-string)
although the exact details are outside the scope of thisSRE SRFI.