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 term
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 d
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 d
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
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". There are No characters as
literals
and supe
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". There are No characters as
literals
and supe
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. Entire. Rule that governs t
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
in this
ticket. No sp
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
in this
ticket. No sp
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
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 well
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 well
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, documentati
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, documentati
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.
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).
Let
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 messages)
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 messages)
“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
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
20 matches
Mail list logo