New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug report: error with \L, \l, \U and \u operators #11145
Comments
From g+i@gameintellect.comHello Perl maintainers, does the operators \L, \l, \U, and \u have right to left associativity, print "\u\LdD\n"; # Dd It seems, first works \L, then \u. Right. print "\L\Ua\n"; # Syntax error, oops! -- |
From @AbigailOn Mon, Feb 21, 2011 at 06:57:58AM -0800, Serge wrote:
All that's being said about priorities in "Gory details of parsing quoted All operations above are performed simultaneously, left to right. Which is vague enough that any behaviour described below can be explained
I tend to agree. I'd expect it to be equivalent to lc ucfirst "dD"; But there's the "left to right" statement. Whatever that means.
That appears to be inconsistent with "\L\udD\n";
That's just plain weird, IMO.
Abigail |
The RT System itself - Status changed from 'new' to 'open' |
From @dcollinsnOn Tue Feb 22 02:31:59 2011, abigail@abigail.be wrote:
This is profoundly strange, and is still in blead as described above. Precedence issues aside, I think that "\L\udD" should eq "dd", and "\L\UdD" should also eq "dd" (and in any event should be valid syntax). I thought I understood how these parsed after digging into the other precedence ticket out there, but evidently I do not. -- |
From @khwilliamsonOn 08/15/2016 10:40 AM, Dan Collins via RT wrote:
The whole thing is broken. I'm not sure I agree with your assessment. IIRC we decided that someone would look thoroughly at the situation and In thinking about it lately, I: a) wonder if we should create a single ticket for this, including \Q, b) note that the regex pattern results diverge from the double-quoted $ blead -le 'print qr/\L\ABCD/' silently turns what probably was meant to be the assertion \A into a $ blead -le 'print "\L\ABCD"' acts like what I consider sanely, as does this: $ blead -le 'print "\l\ABCD"' but I don't know about this: blead -le 'print qr/\l\ABCD/' |
From @cpansproutOn Mon Aug 15 12:00:59 2016, public@khwilliamson.com wrote:
lcfirst '\A' is equivalent to lc('\\') . 'A'. No surprises there. Most of the code that handle this is in the tokenizer. I know that code fairly well, so I could fix it easily. I just need to know *how* things *should* behave. -- Father Chrysostomos |
From @cpansproutOn Mon Aug 15 14:24:23 2016, sprout wrote:
Oh, I see what you are getting at. qq behaves differently, because things happen in a different order: $ perl -lwe 'print "\l\ABCD"' -- Father Chrysostomos |
From @cpansproutOn Mon Aug 15 12:00:59 2016, public@khwilliamson.com wrote:
I think we actually have two separate issues here. This ticket is about \L\l\U\u etc. not ‘nesting’ consistently (sometimes nesting; sometimes not; sometimes implicitly transposed).
And this is a *separate* issue; namely, that regular expressions do not apply character escapes and case modifiers in the same order. They do not have to be fixed at the same time. -- Father Chrysostomos |
From @khwilliamsonOn 08/15/2016 03:54 PM, Father Chrysostomos via RT wrote:
Perhaps not, but any decision will need to consider the effects on the |
As I recently commented on the mailing list: To put my 2c in for this part, it is necessary and useful that certain ones nest:
So unless there's a compelling reason otherwise it seems intuitive for them all to work consistently with that. |
Just wanted to note that double quoted strings and regex behave differently with regards to escape characters necessarily, and that this necessarily interacts with \U \L and friends differently. The basic issue is that in the regex engine escapes do not mean their literal equivalent, and in a double quoted string they do. Arguably in regex quoting \Q \L \U and friends should be deferred to the regex engine, and act as modifiers to the regex parser and not be converted by the toker at all. We should focus on getting the rules right for double quoted strings, and then have the regex engine simulate that as much as is sensible. Consider that |
Migrated from rt.perl.org#84578 (status was 'open')
Searchable as RT84578$
The text was updated successfully, but these errors were encountered: