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
From:
demerphq
Date:
August 2, 2010 01:17
Subject:
Re: qr stringification: why are xism always present? I'm worried about backward compatibility
Message ID:
AANLkTi=iWMgate4AfeP9sF9Xhq4yny85qZVeZ-Kga4o9@mail.gmail.com
On 1 August 2010 21:44, karl williamson <public@khwilliamson.com> wrote:
> Ben Morrow wrote:
>>
>> Quoth public@khwilliamson.com (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

/(?i:foo(?s:[0-9a-f].*))/

Also there is a pesky form like this:

/(?i)foo(?s)[0-9a-f]/

This behaviour must not be changed.

Yves

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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About