one last issue - non-capturing Alex Shinn (08 May 2014 12:26 UTC)
Re: one last issue - non-capturing Peter Bex (08 May 2014 12:45 UTC)
Re: one last issue - non-capturing Alex Shinn (08 May 2014 18:27 UTC)
Re: one last issue - non-capturing Peter Bex (08 May 2014 18:32 UTC)
Re: one last issue - non-capturing John Cowan (09 May 2014 22:23 UTC)
Re: one last issue - non-capturing Alex Shinn (08 May 2014 18:45 UTC)

Re: one last issue - non-capturing Peter Bex 08 May 2014 12:35 UTC

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?

> 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.

> The problem with this is that many people
> will want to implement SRFI 115 on top of
> existing regexp implementations which don't
> support such a feature.  As a workaround you
> can just use named captures exclusively and
> not rely on positions.

I'd prefer a procedure which processes an SRE and strips
all capturing groups.  AFAIK there's not reason this has
to be a native SRE operator.  You could even pass a second
argument indicating whether it should strip named matches,
numbered matches, or both.

Cheers,
Peter
--
http://www.more-magic.net