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

Re: RFC: New regex modifier flags

Thread Previous | Thread Next
karl williamson
August 4, 2010 21:03
Re: RFC: New regex modifier flags
Message ID:
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 
> * 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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About