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 9, 2010 15:38
Re: qr stringification: why are xism always present? I'm worriedabout backward compatibility
Message ID:
Quoth (Aristotle Pagaltzis):
> * <> [2010-08-09 12:10]:
> > there is a new flag, but the default value for the flag is
> > "whatever perl used to do", and that's the only default value
> > we could ever have chosen.
> Right. But we have to add the flag to the stringification even
> though its default means no behavioural change over previous
> versions of Perl.
> What if we add more flags that need to be added to the default
> stringication even though their default setting means no
> behavioural change over previous versions of Perl?
> Then you get the argument we had before. Either `(?~:)` changes
> meaning and patterns used across Perl versions now start meaning
> different things on different Perls; or its meaning never changes
> and you need to add the flags to the default stringification, so
> you get the same breakage we are facing right now.

I don't think so. The way I see this working (please correct me if I'm
making a mistake here) is

    In 5.14, (?~i:) is equivalent to (?id-xsm:), since the default is
    (?d-xism:) and only /i was specified. (I am assuming here that
    we drop the Cd convention in favour of ordinary flags, and that /d
    means 'the old, broken behaviour'.)

    In 5.16, we add (say) flags /w /y /z, where /w is on by default and
    means 'whatever 5.14 did'. (There is no choice about this default,
    since patterns with none of these flags need to mean the same as
    they did before.) (?~i:) becomes equivalent to (?idw-xsm:),
    which *means exactly the same as the 5.14 expansion did*. Thus
    patterns which previously stringified as (?~i:) can continue to do
    so, and the stringification doesn't need to change again.

I should perhaps mention that I *really* don't like the idea of just
using three random letters for a three-way option. It seems
unnecessarily confusing that the way to switch off (?i:) is (?-i:) but
the way to switch off (?u:) is (?d:). There is also the bizarre
side-effect that specifying /d (as a flag) is always redundant, because
it is the default, but it is necessary to reserve a flag letter for it
anyway for the sake of (?:).

A second, not-entirely-related issue, is Yves' idea about a pragma to
set 'default flags' for a given scope. How would these be turned off?
That is, if I say

    use re::flags "i";

how do I then get a pattern without /i? Would it be worth, while we're
discussing flags, reserving uppercase flags for *that* purpose instead,
so I can say

    use re::flags "i";


to get a case-sensitive match? This would of course forbid us from using
uppercase flags for other purposes, like the nasty compatibility hack
that was suggested for /L, or multi-way options like /Cu.


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