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
karl williamson
August 5, 2010 11:31
Re: qr stringification: why are xism always present? I'm worriedabout backward compatibility
Message ID:
H.Merijn Brand wrote:
> On Wed, 04 Aug 2010 22:09:57 -0600, karl williamson
> <> wrote:
>> demerphq wrote:
>>> On 4 August 2010 15:38, karl williamson <> wrote:
>>>> Aristotle Pagaltzis wrote:
>>>>> * Ben Morrow <> [2010-08-01 22:35]:
>>>>>> 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.
>>>>> I’m unsure about how good an idea that is.
>>>>> Presumably the defaults can change in a future version of Perl,
>>>>> in which case a stringified pattern that uses this syntax will
>>>>> mean different things on different Perl versions. In some cases
>>>>> this will even magically do what you want, but it could equally
>>>>> be a pitfall.
>>>> 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.
>>> Except that its been discussed many times that being able to specify
>>> the default flags in a lexically scoped manner would be a useful
>>> feature. So while it might be true that /perl/ will not change the
>>> default flags, it is quite conceivable that perl will provide the user
>>> a way to do so.
>> Certainly, but it's not relevant here, as this construct would not be 
>> affected by those.  (I now think a period is better than an underscore,
> Assuming that the . is the same as the _ in the other thread, ...
> No, as it is not a syntax error at the moment:
> $ perl -we'$a =~ m/foo/i_Cu'
> Bareword found where operator expected at -e line 1, near "m/foo/i_Cu"
> syntax error at -e line 1, next token ???
> $ perl -we'$a =~ m/foo/i.Cu'
> Useless use of concatenation (.) or string in void context at -e line 1.
> Name "main::a" used only once: possible typo at -e line 1.
> in the bottom example, the . is interpreted as a concatenation.
>> so will use that in the examples.)  (?.:foo) would mean this cluster 
>> does not inherit the surrounding flags, but uses the /perl/ default 
>> ones.  (.x:foo) means this cluster does not inherit the surrounding 
>> flags, but uses the /perl/ default ones, but also the x modifier is 
>> selected, whether or not it is a /perl/ default.
>> Whatever the user has chosen to be the default, it will be shown in the 
>> stringification iff it differs from the /perl/ default.
You misunderstood.  We are talking about two different things.  One 
thing is new regex modifiers and what they should be; that is a 
different thread.  The other thing in this thread is using some 
character to symbolize "use the default options" in the stringification 
of a regex.  What I was proposing was that the latter be a '.'.  It 
would only be valid immediately after the '?' in the 
(?.posflags-negflags:foo) construct.  It would not be valid in suffixes.

I had originally proposed it being an underscore, Ben, whose idea it 
was, thought of a tilde.  This is not related to the idea of using an 
underscore in "m/foo/i_Cu" to add clarity to the suffix (and perhaps 
infix) modifiers, except that that if we have underscore mean two 
different things, it would be confusing, so I'm withdrawing my original 
suggestion in favor of using a dot instead, which is illegal currently 
in the proposed context.

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