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]
