develooper Front page | perl.perl5.porters | Postings from August 2010

Re: qr stringification: why are xism always present? I'm worriedabout backward compatibility

Thread Previous | Thread Next
Ben Morrow
August 1, 2010 13:31
Re: qr stringification: why are xism always present? I'm worriedabout backward compatibility
Message ID:
Quoth (karl williamson):
> Ben Morrow wrote:
> > Quoth (karl williamson):
> >>
> >> But there must be some reason that xism are always shown in the 
> >> stringification, whether they are in effect or not in effect.  But I 
> >> can't think what it might be.  It would have been simpler for the 
> >> original design to only output them in the stringification when 
> >> different from the default.  So there must be a reason why the plus or 
> >> minus of them is always output.  Does that reason apply to these new 
> >> modifiers?
> > 
> > The reason is so that interpolation under different flags works
> > properly. Currently, if I have
> > 
> >     my $rx = qr/f./s;
> > 
> > is stringifies to (?s-xim:f.), which means that when I interpolate it
> > into a pattern with different flags
> > 
> >     "AFx" =~ /a$rx/i;
> > 
> > the /i is 'cancelled' for the duration of the interpolation (and /s
> > activated). If it were changed to stringify to (?s:f.) only, the match
> > above would change from failing to passing.
> I still don't understand.  I had considered interpolation, and it still 
> seems to me that the absence of a modifier means use the underlying 
> default for the duration of that interpolation, no matter what the outer 
> regex says.  I don't see a flaw in that thinking.

Um, it's not what actually happens :)?

    ~/src/perl% perl -E'say "F" =~ /(?s:f)/i'
    ~/src/perl% perl -E'say "F" =~ /(?s-ixm:f)/i'


Complete absence of a modifier means 'leave this modifier as it was
outside this group'. I don't think that can (or should) be changed now.

As Avar said, this could potentially be changed for the simple case of
direct interpolation, by looking up the flags on the interpolated regex
directly. However, a lot of code assumes it can stringify a qr//, write
it to a file/pass it across the network/whatever, and re-qr// to get an
equivalent pattern back.

My alternative suggestion was to introduce a new grouping construct,
which I tentatively called (?~sixm:) (I don't much like that, but there
aren't many alternatives at this point), which *does* do what you
expect; and use that for stringification instead. That way we change the
stringification once, now, and then never again.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About