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

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

Thread Previous | Thread Next
June 8, 2010 08:31
Re: PATCH: [perl #58182] partial, "The Unicode Bug". Add unicodesemantics for \s, \w
Message ID:
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  
>> < <>> 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". It's great
if ones goal is to write code that outputs different things depending on
different versions (the more different things the better), but in general,
no. But I like the idea of "see if the modifiers spell something else first".

Why not:

    - read the modifiers; if it can be consider as a statement modifier
      or binary operator, do so (with the exception of the existing /x).
    - else, treat them as modifiers.

Do this for 5.14, 5.16, 5.18, etc.

If that means that '/foo/le;' will be parsed as '/foo/ le;', and then die
as a syntax error; then so be it. /l doesn't exist yet, so one can always
learn to write '/foo/el;'.


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