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 9, 2010 03:05
Re: qr stringification: why are xism always present? I'm worried about backward compatibility
Message ID:
karl williamson <> wrote:
:Ben Morrow wrote:
:> Quoth (Aristotle Pagaltzis):
:>> * karl williamson <> [2010-08-05 19:25]:
:>>> Aristotle Pagaltzis wrote:
:>>>> * karl williamson <> [2010-08-04 15:40]:
:>>>>> FWIW, I have given this some thought, and came to the
:>>>>> conclusion that Perl is almost certainly never going to
:>>>>> change the defaults, because of the backward compatibility
:>>>>> issues.
:>>>> Yet you *are* changing the past default right now, *in spite*
:>>>> of back compat issues… :-)
:>>> I'm not sure I understand. The default options remain the same.
:>>> Ben made the point in your quote above that by doing this now
:>>> when we are pretty much agreed that something should be done
:>>> will cause this to likely be the last time adding a flag would
:>>> cause backward compatibility issues.
:>> If the default is not allowed to change again, then we gain
:>> nothing from `(?~:)`.
:> Right.
:>> Right now, the problem is that the default is changing, such that
:>> `(?-xism)` is not an accurate representation of it.
:> Right.
:>> This is caused by the fact that we are introducing a flag that
:>> *requires* a choice of default.
:>> What happens if we run into this situation again in the future?
:>> If the meaning of `(?~:)` is not allowed to change, then it will
:>> no longer be an accurate representation, so patterns will have to
:>> stringify to `(?~Xy:)`.
:> Wrong. (?~:), with no further flags, means 'The default, whatever that
:> happens to be in this version of perl'. If we later introduce flags Xy,
:> Xz and Xw such that one of these must be specified, and Xy is the
:> default, then (?~:) with no mention of any X* flag will imply Xy. Thus
:> in
:>     /foo(?~:bar)baz/Xz
:> 'bar' will be matched with /Xy in effect, rather than /Xz.
:> (As a separate issue, presumably /Xy in such a case would correspond to
:> the current semantics, or a bug-fixed version thereof, with /Xz and /Xw
:> invoking new semantics.)
:>> (Personally I would rather skip the entire discussion and train
:>> people to do
:>>     ( my $re_defaults = "" . qr/ / ) =~ s/ //g;
:>> and use *that* instead of hardcoding *either* `(?-xism:)` *or*
:>> `(?~:)` *or* anything else, because that’s guaranteed to yield
:>> the right default stringification now and forever.)
:> +1. I'm beginning to regret suggesting the idea in the first place...
:> Ben
:I guess I'll drop this too, as I'm apparently the last person who thinks 
:it is a good idea.  The problem with I see in Aristotle's suggestion is 
:that how do people get trained?  It's not an obvious solution or we 
:wouldn't have the various cases where things break.

Sorry I haven't commented before - I think it is a great idea.

I'm not in love with any of the characters I've seen proposed to signify
this (though I definitely prefer '~' to '.'), but I am in love with
the idea that after rolling this out, adding any new modifier should leave
the stringification of all previous regexps unchanged, and thus avoid
breaking existing tests.

I do not believe the "what if we change the default" argument has any
relevance - it's not something we can ever do, because it would change
the meaning of every regexp ever written for which that particular flag
had not explicitly been specified. Ben's argument that "right now the
default is changing" is incorrect - 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.


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