Re: one last issue - non-capturing

[Alex Shinn <alexshinn@xxxxxxxxx>]

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

sense.

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

intended.

-- 

Alex