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

Re: one last issue - non-capturing

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 Thu, May 8, 2014 at 9:35 PM, Peter Bex <Peter.Bex@xxxxxxxxx> wrote:
On Thu, May 08, 2014 at 09:26:51PM +0900, Alex Shinn wrote:
> SCSH SREs support controlling of capturing
> or not with the use of , vs ,@.
> It's trivial to write a utility to strip away capturing
> groups from an SRE, and is useful enough that
> we may want to include this as syntax:
>   (w/nocapture sre ...)
> which would strip all capturing groups from the
> enclosed SREs.  There is no corresponding
> w/capture, which would defeat the purpose.

Why does there need to be a syntax for this?

Currently we don't define any utility procedures
for manipulating SREs, and its use is analogous
to e.g. w/nocase, for which the same argument
holds, so for consistency the syntax made more

You can always make a procedure if needed:

  (define (w/nocapture . args)
    (regexp->sre `(w/nocapture ,@args)))

> Ideally I like the idea of libraries of regexps,
> along the lines of Perl's Regexp::Common,
> where this would be most useful.  An even
> better option is the notion of named but non-
> numbered capturing groups, where library
> regexps could advertise the named groups
> they provide without affecting your counts.

I like that idea.  I always found it rather confusing
that names were _also_ numbers.

This, however, is how PCRE and most other
libraries work.  I thought it was ubiquitous but
apparently .NET did the right (?) thing and broke
with tradition here.

If we did use .NET semantics, SREs would no
longer simply be an alternate syntax for PCREs,
and would become a combination of a PCRE plus
set of index mapping rules, and the proposed
future procedure sre->pcre would not work as