Re: [perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

On Thu, Jun 8, 2017 at 6:22 AM, Zoffix Znet via RT < perl6-bugs-follo...@perl.org> wrote: > > m: sub infix:<2> { $^a + $^b }; say 2 2 2 > rakudo-moar 1ac799: OUTPUT: «4␤» > > Because when an op is expected. There's just one op named `2`. And when > a term is expected, there's just one

[perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

After a conversation in #perl6-dev[^1], I'm rejecting this ticket. Unlike invisible operators (RT#128159), there's no security risk involved. Unlike `&0` (RT#128159), there's no ambiguity in what the non-throwing behaviour is supposed to be. This is just a peculiar intersection of two very-well

[perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

After a conversation in #perl6-dev[^1], I'm rejecting this ticket. Unlike invisible operators (RT#128159), there's no security risk involved. Unlike `&0` (RT#128159), there's no ambiguity in what the non-throwing behaviour is supposed to be. This is just a peculiar intersection of two very-well

Re: [perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

I do understand the operand-operator idea now, but I think that allowing the same symbol to be both operand and operator is a terrible idea. Feel free to disagree, I'm not going to argue that point. Otherwise: And since nobody is going to use that > > Yes! Exactly. You've put the nail in your

[perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

Quoting Joachim Durchholz : > Am 08.06.2017 um 01:11 schrieb Zoffix Znet via RT: >> Quoting Joachim Durchholz : > That cannot be correct. There's that other rule that turns > superscripts into exponents. Except it IS correct. There's no "other rule".

Re: [perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

Am 08.06.2017 um 01:11 schrieb Zoffix Znet via RT: Quoting Joachim Durchholz : Actually I'd like to *remove* a special case: That ² is to be interpreted as 2 But it's NOT a special case. You can use any character with No property as a numeric literal. That's. The.

[perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

Quoting Joachim Durchholz : > Actually I'd like to *remove* a special case: That ² is to be interpreted as 2 But it's NOT a special case. You can use any character with No property as a numeric literal. That's. The. Entire. Rule that governs the behaviour under examination

Re: [perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

Am 07.06.2017 um 23:09 schrieb Zoffix Znet via RT: What baffles me is we have several people calling for the ban on The Superscripts yet, no one appears appear to have any issues with ⅟², ၓ², ౸², ㆒², ̣², and ၒ² which are also perfectly valid sequences. I would have issues with these if I had

[perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

On Wed, 07 Jun 2017 14:09:25 -0700, j...@durchholz.org wrote: > There's also the issue that undefined behaviour tends to become exploitable > as part of a security hole. > So I'm seconding Alekx-Daniel on this. It's not undefined. My entire point is the reason these sequence parse is due to

[perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

On Wed, 07 Jun 2017 14:09:25 -0700, j...@durchholz.org wrote: > There's also the issue that undefined behaviour tends to become exploitable > as part of a security hole. > So I'm seconding Alekx-Daniel on this. It's not undefined. My entire point is the reason these sequence parse is due to

[perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

On Wed, 07 Jun 2017 08:48:20 -0700, alex.jakime...@gmail.com wrote: > We had a bunch of segfaults Segfaults are program memory access errors. Here, we're talking about well-defined behaviour that you wish to make more complex on entirely arbitrary whim by special-casing the compiler,

Re: [perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

On 6/7/17, Joachim Durchholz wrote: > There's also the issue that undefined behaviour tends to become > exploitable as part of a security hole. > Or, even worse, depended on for some perverse result.

Re: [perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

There's also the issue that undefined behaviour tends to become exploitable as part of a security hole. So I'm seconding Alekx-Daniel on this. Am 07.06.2017 um 17:48 schrieb Aleks-Daniel Jakimenko-Aleksejev via RT: (for example, because this kind of stuff makes the language look fragile).

Re: [perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

When I first started programming, any program that took physical input (which had usually been keyed very accurately by reliable young women) had to pass a test. It was fed its own machine code, backwards. It was expected to reach a normal EOJ, (albeit with a significant output of error

Re: [perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

When I first started programming, any program that took physical input (which had usually been keyed very accurately by reliable young women) had to pass a test. It was fed its own machine code, backwards. It was expected to reach a normal EOJ, (albeit with a significant output of error

[perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

“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

[perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)

FWIW, 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