Front page | perl.perl5.porters |
Postings from May 2010
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?Thread Previous | Thread Next