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

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

Thread Previous | Thread Next
karl williamson
May 19, 2010 12:47
Re: PATCH: [perl #58182] partial, "The Unicode Bug". Add unicodesemantics for \s, \w
Message ID:
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?

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