Front page | perl.perl5.porters |
Postings from August 2010
Jesse Vincent wrote: > Karl, > > We've been discussing one possible solution to the modifier vs previously > allowed keywords problem on #p5p this morning: > > * 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'? > > * 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" > * 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 would oppose that. I've known for maybe 40 years that it's a bad idea to not require some sort of delimiters around keywords, which is precisely the situation we have here, although I guess (hope) it snuck in and wasn't deliberate. I still remember (and hope I've got it right) the classic example from Fortran 66: DOI=JTON could be setting a variable to another one, or it could be the beginning of a loop. It caused compiler writers headaches. It's a shame to see well-known mistakes keep being repeated. > > Would that work for you? > > -Jesse > > > [1] or some to-be-named use feature '...' pragma. > > -Jesse > 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 also like the idea, that since these are mutually exclusive, specifying more than one of them is a syntax error, and not "last one on the line wins" that I originally proposed. I have already implemented the two letter Uppercase and sub-modifier, which I thought was the consensus last go round. But I've been somewhat leery of that proposal, but not sure why. If we were to go with that, I think optional underscores as was proposed earlier would be an excellent addition. I'm wondering if having optional underscores separating single letter lowercase modifiers for added clarity is useful even if we don't at this time have two letter modifier clusters. I don't know.Thread Previous | Thread Next