Front page | perl.perl5.porters |
Postings from June 2010
On 8 June 2010 17:32, Abigail <abigail@abigail.be> 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 >>> <public@khwilliamson.com <mailto:public@khwilliamson.com>> 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/"Thread Previous | Thread Next