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

Re: RFC: New regex modifier flags

Thread Previous | Thread Next
karl williamson
August 6, 2010 04:37
Re: RFC: New regex modifier flags
Message ID:
David Golden wrote:
> On Thu, Aug 5, 2010 at 5:02 PM, karl williamson <> wrote:
>>> * With "use 5.14", the new modifiers may be used either in (?:) or as
>>> trailing modifiers.  Any "run-on" keyword is a syntax error.
>> Why forbid using the suffix form in the cases where there is no ambiguity?
>>  That seems wrong to me; it would be quite rare actually for the ambiguity
>> to arise, so why not (since I'm willing to do the work) make it so that "use
>> 5.14" essentially just changes to which side any ambiguity resolves?   That
>> doesn't harm pre-existing code, and lets new code get the advantage of the
>> new modifiers in many more situations than otherwise (almost all, in fact).
>>  We could easily differentiate between a for-certain run-on case and an
>> ambiguous case, and output different messages.  For the ambiguous ones, it
>> could be something as extensive as "'/regex/le foo' ambiguous; resolved to
>> '/regex/ le foo'; in 5.16 or in scope of 'use 5.14" will resolve to
>> '/regex/el foo'"
> My thought for why not to allow them when there is no ambiguity is to
> avoid having to explain the special cases.  I much prefer something
> very clean and binary.  With "use 5.14" and you get the (trailing)
> modifiers.  Without it, you don't, but can still do them long-hand
> with (?:).  That's really, really easy to explain.  And then in 5.16,
> it all just works.
> So just because we *can* DWIM in many cases doesn't mean we should.
>> And what to call the underlying feature?  Since it's designed to be
>> temporary, could its name just begin with an underscore and not be
>> documented other than that the feature bundle 5.14 includes it?  Or would it
>> be necessary to decouple it from the other features that "use 5.14" enables?
> My first thought was 'charset_modifiers'.  And then for 5.16, it does
> nothing if turned on and maybe warns if turned off.
> -- David

I did an analysis of this, and it turns out that the only ambiguous case 
is 's/foo/bar/le'.  It seems like overkill for this to invent a new 
temporary pragma, and forbid all the new modifiers as suffixes, when 
there is no ambiguity at all outside of substitutions, and no ambiguity 
  using substitutions except for one  combination out of all those 
possible.  Why can't we just say in the pods and warning message that 
'/le'  must be written as '/el' in 5.14?

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