Re: PATCH: [perl #58182] partial, "The Unicode Bug". Add unicode semantics for \s, \w

On 8 June 2010 17:32, Abigail <[email protected]> wrote:
> On Wed, May 19, 2010 at 01:46:49PM -0600, karl williamson wrote:
>> Eric Brine wrote:
>>> On Wed, May 19, 2010 at 2:20 PM, karl williamson
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>>     I don't understand these preclusions.  Why, for example, does the
>>>     existence of 'and' preclude /a, but the existence of 'unless' not
>>>     preclude /u ?
>>>
>>>
>>> When used as a statement modifier.
>>>
>>> $ perl -le'$x+=/foo/unless$c; print "ok"'
>>> ok
>>>
>>> If we add /u, the above would die as follows:
>>>
>>> Bareword found where operator expected at -e line 1, near "/foo/unless"
>>>         (Missing operator before nless?)
>>> syntax error at -e line 1, near "/foo/unless"
>>> Execution of -e aborted due to compilation errors.
>>>
>>> "Preclude" is not quite the right word, at least not on its own. They
>>> preclude the addition of the modifier without some form of conflict
>>> resolution. Most of the conflicts can even be resolved cleanly by
>>> lookahead. (/l isn't resolved cleanly by lookahead.)
>>>
>>>
>>>     Instead of creating a syntax error, we deprecate in 5.14 not
>>>     inserting a space between a pattern terminator and the following word.
>>>
>>>
>>> That still breaks backwards compatibility, and we'd have to wait for
>>> 5.016 to get /u and /l in.
>>>
>>> "use 5.014;" avoids both the break and the wait. It could either add /u
>>> and /l, or it could add the space requirement.
>>>
>>
>> I don't think you understood my suggestion; everything would take effect
>> in 5.14.  What I meant is that we could resolve things like the "unless'
>> by lookahead.  That is we special case the l and u (and /a if we get it)
>> modifiers so that they don't take effect if the word they're in is a
>> legal one; the complete list of which you've given (I think).
>>
>> The algorithm would be: the code would look first for the 5.12 modifier
>> set, as currently.  If that exhausts the word, continue as currently.
>> Otherwise if the word is one of the few you've mentioned, also continue
>> as currently, but raise the deprecated warning.  Otherwise, reparse the
>> word, this time allowing the new modifiers.  If that exhausts the word,
>> fine, we've got our modifiers.  If not, raise the deprecated warning.  A
>> syntax error would also be generated if the word isn't recognized.
>>
>> This would guarantee backward compatibility, with no inappropriate
>> syntax errors.  /lt and /le would be resolved by documenting that these
>> have the 5.12 meanings.  This would be lifted in 5.16 after the
>> deprecation cycle.
>>
>> I think the reasons to prefer my solution over yours is that it doesn't
>> require a 'use 5.014'; which I always forget to include, and I prefer
>> doing deprecation instead of syntax errors.  (My first take is that
>> modifying the 'use 5.014' solution to do deprecation would be very
>> similar to taking my suggestion.)
>>
>> Otherwise, I'm fine with yours, except it requires me to learn a new
>> area of Perl in order to make the patch. :)
>> Does anyone else have an opinion?
>
>
> I'm not found of "we're now going to introduce a behaviour change - part
> of its to warn for another behaviour change in the next release".

I don't see any other choice given our deprecation policies.

Yves


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