Front page | perl.perl5.porters |
Postings from August 2010
David Golden wrote: > On Thu, Aug 5, 2010 at 12:03 AM, karl williamson > <public@khwilliamson.com> wrote: >> Jesse Vincent wrote: >>> * If the user declares "use 5.14"[1] for the current lexical scope, then >>> the modifiers previously allowed without spaces would become syntax errors. >> That doesn't make sense to me. Do you mean 'keywords' instead of >> 'modifiers'? > >>From the IRC discussion, that's what he meant. > >>> * If the user declares "use 5.14" for the current lexical scope, then >>> they get the new regex modifiers without any crazy required syntax. >>> >> I'm not sure again what you mean. Using uppercase modifiers doesn't >> conflict with existing syntax; there have been two flavors of that proposed, >> and each has their adherents who I doubt view these as "crazy" > > I'll stand up and say that I think upper case and doubled modifiers > are relatively "crazy" and I'd prefer to avoid them if we can find > less surprising alternatives. ok > >>> * If the user doesn't declare "use 5.14", then they get the bad, old >>> behavior that we all agree is a flaw, but that people are invariably >>> depending on in old code. >> And do we remove the deprecation message for that? > > I think we should keep the deprecation without "use 5.14". Then in > 5.16 we make it a syntax error and no longer require "use 5.14" for > the new modifiers. > >> I would be comfortable with something similar to the following, since it >> appears the discussion was ruling out the upper case modifiers: >> >> New regex modifiers are added in 5.14. Using them doesn't require a "use >> 5.14". However, if their use in combination with other modifiers happens to >> spell an existing keyword that keyword is assumed if and only if NOT in the >> lexical scope of a "use 5.14". And, they get a deprecation message if they >> don't have a space before that keyword. The implications are that all the >> new modifiers in 5.14 are usable as /suffixes and as (?infixes:) but a few >> suffix combinations are invalid unless there is a "use 5.14". > > I think it can be simpler: > > * Without "use 5.14", the new modifiers can only be used in (?:). Any > "run-on" keyword (without a space) is valid but issues a deprecation > warning. > > * With "use 5.14", the new modifiers may be used either in (?:) or as > trailing modifiers. Any "run-on" keyword is a syntax error. Why forbid using the suffix form in the cases where there is no ambiguity? That seems wrong to me; it would be quite rare actually for the ambiguity to arise, so why not (since I'm willing to do the work) make it so that "use 5.14" essentially just changes to which side any ambiguity resolves? That doesn't harm pre-existing code, and lets new code get the advantage of the new modifiers in many more situations than otherwise (almost all, in fact). We could easily differentiate between a for-certain run-on case and an ambiguous case, and output different messages. For the ambiguous ones, it could be something as extensive as "'/regex/le foo' ambiguous; resolved to '/regex/ le foo'; in 5.16 or in scope of 'use 5.14" will resolve to '/regex/el foo'" > * In 5.16, the new modifiers are always available and run-ons are > always a syntax error. Whatever feature is added in 5.14 to enable > the new behavior becomes a no-op. > > For clarity, I think this proposal includes the idea that using more > than one mutually exclusive modifier, whether in (?:) or trailing, is > a syntax error. > ok, and thank you. > -- David > And what to call the underlying feature? Since it's designed to be temporary, could its name just begin with an underscore and not be documented other than that the feature bundle 5.14 includes it? Or would it be necessary to decouple it from the other features that "use 5.14" enables?Thread Previous | Thread Next