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

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

Thread Previous | Thread Next
August 2, 2010 01:17
Re: qr stringification: why are xism always present? I'm worried about backward compatibility
Message ID:
On 1 August 2010 21:44, karl williamson <> wrote:
> Ben Morrow wrote:
>> Quoth (karl williamson):
>>> The reason is that the code always outputs the modifier, even for the the
>>> existing semantics, so the stringification is permanently different from
>>> before.  That got me to thinking that it should be possible to omit the
>>> modifier from the stringification unless it is different from the default.
>>>  Thus backward compatibility would not be broken, although it is a dangerous
>>> thing for modules to be relying on knowing all the possible modifiers, and
>>> someone could pass them a regex compiled with a new modifier that they don't
>>> know how to deal with, not just these, but any new ones.
>>> 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.
>> So yes, this applies to your new modifiers as well. Every stringified
>> qr// should include a Cx flag of some kind. The only sane alternative
>> would be to break compat once, now, by changing the stringification to
>> something like (?~s:f.), using a new pattern which guarantees to set all
>> non-specified flags to the default for the duration of the group rather
>> than leaving them as they were outside. This would allow adding more
>> flags in the future without breaking compat more than is strictly
>> necessary.
> 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.

Because it would break


Also there is a pesky form like this:


This behaviour must not be changed.


perl -Mre=debug -e "/just|another|perl|hacker/"

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