Re: perl6-language-regex summary for 20000831

On Thu 31 Aug, Mark-Jason Dominus wrote:
> Summary report 20000831

> RFC 110: counting matches  (Richard Proctor)
> 
> An extensive side discussion of
> 
>         $count = () = m/PAT/g;
> 
> developed, including an excursion off into context issues.  I have
> asked the author to take this idiom into account in the next version
> of the RFC.

Expect this tommorrow.

> RFC 112: Assignment within a regex  (Richard Proctor)
> 
> Very little discussion.  This should be compared with RFC 150 and
> perhaps be folded into it.

There where four "This is wonderful" type messages between here and its
original posting on language.  I suspect that things people agree with
don't get much discussion.

> RFC 144: Behavior of empty regex should be simple  (Mark Dominus)

I agreed with the RFC - no discussion needed.

> RFC 165: Allow variables in tr///  (Richard Proctor)
> 
> I pointed out that the implementation would have construct the
> translation table at run-time, and that this brings in the same issues
> as when a regex is constructed at run time.  For example, a new tr///o
> option becomes desirable for the same reaosn the m//o is desirable.

I have captured that for the next issue.

> RFC 166: Additions to regexs  (Richard Proctor)
> This RFC unfortunately proposes three totally unrelated changes.

I should split it.

> Richard proposed a 'does not match' operator, with the example that
> 
> Richard said he would tighten up the definition, but
> version 2 has not appeared yet.

Working on it - There are big cavens opening up.  When I have a solution
I will post this in a new RFC, as it will probably have to include other 
things.

> Richard also proposed a (?) operator that would match the empty
> string.  You would use this in cases like /$foo(?)bar/ where it is
> inappropriate to abut $foo and bar.  It was pointed out that
> /${foo}bar/ and /$foo(?:)bar/ already work for this purpose.  Richard
> agreed that this was what he wanted.

Consider it dropped.

> The third proposal was that (?@foo) be taken to interpolate the string
> (join "|", @foo).  There was no discussion of this.

I will make a RFC166 V2 that has just this.  It also proposed a 
quoted varient (?Q@foo) that effectively did quotemeta on each item.

Richard

-- 

[email protected]