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
Problem with superscripts when there is no number in front of it (³² == 9) #4787
Comments
From @AlexDanielCode: Result: This should probably be a syntax error. |
From mattoates@gmail.comIf no other numeric literal is given as a base along with the unicode $ perl6 |
From @zoffixznet| This should probably be a syntax error. There's an agreement on that. Possibly to force the user to add parentheses: (³)² == 9 There's been a discussion on the topic today, including for why such behaviour is observed: http://irclog.perlgeek.de/perl6/2016-07-05#i_12788472 Since superscripts are 'No' category, the first digit so it's the same as ⑤², except with ³ instead of ⑤ |
The RT System itself - Status changed from 'new' to 'open' |
From @ronaldxsLooks like it should be merged with https://rt-archive.perl.org/perl6/Ticket/Display.html?id=126732 |
The RT System itself - Status changed from 'new' to 'open' |
From @zoffixznetFWIW, I rescind all of my previous comments on the matter and now think no special casing should be done to error out on ³² or anything like that. The only people I see complaining about it are those who just type it up randomly to see what it'd do; i.e. not an issue in real programs. I see no sufficient argument to add special casing in code, documentation, and tests, without solving any real problems. |
1 similar comment
From @zoffixznetFWIW, I rescind all of my previous comments on the matter and now think no special casing should be done to error out on ³² or anything like that. The only people I see complaining about it are those who just type it up randomly to see what it'd do; i.e. not an issue in real programs. I see no sufficient argument to add special casing in code, documentation, and tests, without solving any real problems. |
From @zoffixznetMore commentary on the issue: https://irclog.perlgeek.de/perl6/2017-06-05#i_14686462 Looking at all the No chars ( https://gist.github.com/Whateverable/02fff4038552bff6f31f34042016cb9eb ) there are plenty of candidates that look even worse than two superscripts. So IMO, this ticket is a clear candidate for rejection. |
From @AlexDaniel“The only people I see complaining about it are those who just type it up randomly to see what it'd do” We had a bunch of segfaults and overflows that could only be caused by people throwing random stuff into the compiler. And yes, very often we had to go through this “wait, but normal people will not see this” idea, and in every case it was fixed in rakudo instead (for example, because this kind of stuff makes the language look fragile). Let's resolve the issue by adding an error message and not by closing our eyes on this. On 2017-06-05 03:19:58, cpan@zoffix.com wrote:
|
From @zoffixznetOn Wed, 07 Jun 2017 08:48:20 -0700, alex.jakimenko@gmail.com wrote:
Segfaults are program memory access errors. Here, we're talking about well-defined What baffles me is we have several people calling for the ban on The Superscripts yet, no one appears The price of your proposal is unwanted complexity and IMO your justification for introducing it is entirely |
From @zoffixznetOn Wed, 07 Jun 2017 14:09:25 -0700, jo@durchholz.org wrote:
It's not undefined. My entire point is the reason these sequence parse is due to well defined behaviour What's undefined is why you, and Alex-Daniel you're seconding, here are choosing to ban superscripts. If it's aesthetics alone, |
From @zoffixznetQuoting Joachim Durchholz <jo@durchholz.org>:
But it's NOT a special case. You can use any character with No property as a numeric There's quite a bunch of these chars: https://gist.github.com/Whateverable/d94b6a42532a4c1262df794d9be799f3 So just as you can write: You can write: <Zoffix> m: say ²² In BOTH of these cases a No numeral is used with a ² "postfix n" operator.
<Zoffix> m: say 3²
<Zoffix> m: my \x = 42; say x²
<Zoffix> m: dd [.unival, .uniprop] with '²' As you can see above, ² is indeed a `No` char, and it's Unicode numeric value is 2, which is
No, the description above is incorrect and conflates `Nd` Unicode characters that can be
That statement is incorrect. It doesn't.
There's no special casing. There's just one rule: "you can use `No` characters as numerals". Simple. Elegant. Easy to remember. |
From @zoffixznetQuoting Joachim Durchholz <jo@durchholz.org>:
Except it IS correct. There's no "other rule". There are No characters as literals
I already explained that. Perl 6 expects an operator at that position. That's
Except they do. This isn't a detail of parsing. It's the way the language works
It interprets 2 just the same way. There's no ambiguity in this code: <Zoffix> m: sub infix:<2> { Because when an op is expected. There's just one op named `2`. And when
Yes! Exactly. You've put the nail in your own coffin with that one. No one ever And if you still maintain that ²² should be banned. I invite you to answer my |
From @zoffixznetAfter a conversation in #perl6-dev[^1], I'm rejecting this ticket. Unlike invisible operators (RT#128159), there's no security risk involved. [1] https://irclog.perlgeek.de/perl6-dev/2017-06-08#i_14703885 |
@zoffixznet - Status changed from 'open' to 'rejected' |
From @zoffixznetTests covering the discussed behaviour: Raku/roast@a520037d7f |
Migrated from rt.perl.org#126732 (status was 'rejected')
Searchable as RT126732$
The text was updated successfully, but these errors were encountered: