|
00:45
summerisle left,
summerisle joined
01:27
librasteve_ left
06:05
Pixi left
06:18
Pixi joined
|
|||
| Geth | rakudo/main: 5e1832415f | (Elizabeth Mattijsen)++ | src/Perl6/Actions.nqp Give enum A (a => 3.14, b => 6) a better error message Before it was the LTA message: ===SORRY!=== Error while compiling -e Incompatible MROs in P6opaque rebless for types Int and A ... (6 more lines) |
11:52 | |
| rakudo/main: b7a4e1a9eb | (Elizabeth Mattijsen)++ | src/Raku/ast/type.rakumod RakuAST: give enum A (a => 3.14, b => 6) a better error message Basically a repeat of 5e1832415f for RakuAST. Also make sure that trying to enum a type object creates a X::NYI error, just as in the legacy grammar |
12:26 | ||
| rakudo/lizmat-sane-mod-div: 794c807588 | (Elizabeth Mattijsen)++ | src/core.e/Fixups.rakumod Make semantics of div / mod Int only in 6.e In response and as a solution to: github.com/Raku/problem-solving/issues/326 github.com/Raku/problem-solving/issues/504 With having the behaviour of mod in there for multiple years, it ... (5 more lines) |
14:05 | ||
| rakudo: lizmat++ created pull request #6070: Make semantics of div / mod Int only in 6.e |
|||
| nemokosch | I have to be honest, it feels desperate | 14:53 | |
| it feels desperate that a PR pops up that seems to neglect the whole discussion that happened | 14:55 | ||
| when I finally thought I found a way to de-escalate a loaded topic and make a suggestion that sits well with everybody, a PR does the polar opposite | 14:56 | ||
| a suggestion that seems to include librasteve's suggestion from months ago so no claims of originality here | 14:57 | ||
| it's not "how dare you do something I don't agree with", not at all, it's the feeling of neglection, I tried to be as diplomatic while still rational as I could, and it just got sent to the trash bin | 15:03 | ||
| without even unpacking | |||
| lizmat | I think the PR indicates that: | 15:05 | |
| 1. the change in 2024 was an error that shouldn't have happened, but sadly did not cause any spectest or blin fallout | 15:06 | ||
| 2. since div is an Int alternative for / and mod is an Int alternative for %, it makes sense to just allow for Int arguments in the div/mod cases to prevent improper use | 15:07 | ||
| nemokosch | the PR certainly makes sense | ||
| lizmat | 3. since the error has been in releases for 2+ years, any fixes would require a language level | 15:08 | |
| bump | |||
| nemokosch | but I don't think it reflects in any way on the whole discussion that unfolded | ||
| most notably it still means that the docs need to be tinkered with, and arguably Roast as well | |||
| lizmat | indeed... docs would need to mention the changed semantics from 2024.x onward | 15:09 | |
| and changed semantics in 2026.x forward in 6.e | |||
| and there would need to be tests added to roast so that we don't regress again in the future | |||
| nemokosch | on a more personal level, as many times expressed, I don't want the reverted behavior "for good", and I don't think we ever made it to the point (since the unfortunate opportunistic modification in 2024) to have a proper discussion about that | 15:11 | |
| if the fix for the current behavior happens in v6.e, this is again postponed for eternity | 15:14 | ||
| lizmat | "3. since the error has been in releases for 2+ years, any fixes would require a language level bump" | 15:17 | |
| nemokosch | I don't think this is a clean-cut choice | ||
| the right behavior has been in releases for almost 9 years | |||
| to this date, it's in the docs | |||
| lizmat | docs say: multi infix:<div>(Int:D, Int:D --> Int:D) | 15:18 | |
| nemokosch | anything written you can find, suggests that behavior, or something along those lines | ||
| lizmat | docs say: multi infix:<mod>(Int:D $a, Int:D $b --> Int:D) | ||
| nemokosch | if one can break things 6 years into 6.d, it's not clear why one couldn't un-break them 2 years later | 15:19 | |
| lizmat | that's what the PR essentially codifies in 6.e | ||
| docs would only need to mention difference from documented behaviour for the given release periods / language levels | |||
| nemokosch | when is 6.e going to be released? | ||
| like, people don't get the fix immediately, and the whole discussion about '5' div '3' could only ever happen way after | 15:20 | ||
| this is another angle to look at it | |||
| lizmat | you can already do "use v6.e.PREVIEW" now | 15:22 | |
| nemokosch | you might as well do use SANE-DIV-MOD by the same chance | 15:25 | |
| lizmat | % rak --eco-provides 'use v6.e.PREVIEW' --or='use v6.*' --count-only | ||
| 342 matches in 342 files | |||
| nemokosch | I see the arguments, I don't think they are overwhelming, and then they haven't been made | 15:26 | |
| lizmat | I like the code speak of the arguments, if at all possible | 15:29 | |
| nemokosch | I for one don't think this is the right time to be pendantic about backwards compatibility | ||
| if this was about the 2024.02 change, ideally changes like that shouldn't be made | 15:30 | ||
| lizmat | it is *always* the right time to be pedantic about backwards compatibility | ||
| nemokosch | then why is that Rakudo has broken compatibility several times even in the last 2 years? | ||
| lizmat | yes, but it did, and it happened, and saying: it shouldn't have happened is not productive | ||
| nemokosch | why is it that Range.min got repurposed into something it wasn't meant to be | ||
| why is it that reductions treat single arguments differently now | 15:31 | ||
| lizmat | well, you do have a point there | ||
| nemokosch | I will say it once more: this is not the time to be pedantic | ||
| lizmat | I don't see how broken backward compat in the past is a reason for allowing it in the future | 15:32 | |
| nemokosch | my point is that now we have the worse of both worlds | ||
| keeping compatibility with things that are bugs for all intents and purposes, while design changes in prod were fine | 15:33 | ||
| it would still be better to just break bugs alike | |||
| [Coke] | "in prod"? | 15:34 | |
| nemokosch | yes | ||
| [Coke] | I mean: please define what you mean by "in prod" - for an app that makes sense, but I don't understand exactly what you're saying in this context. | 15:35 | |
| nemokosch | then please consider rakudo an app | 15:36 | |
| librasteve | just saw this thread, I agree with @nemokosch on not perpetuating the bug introduced in 2024.x (I have commented in the PR also) | 17:04 | |
| nemokosch | I don't know by now what remark belongs to which IRC channel, hoping this makes sense for the following remark | 17:32 | |
| I took a look at the implementation of gcd and I'm reassured that it has exactly the same circumstances as div | 17:34 | ||
| which may mean they are both wrong but anyway | |||
| lizmat | the difference being that there is *no* non-int equivalent for gcd | 17:35 | |
| while there *is* for div (/) and mod (%) | |||
| nemokosch | I don't think that's a relevant difference though | 17:36 | |
| of course "greatest common divisor" is an integer arithmetic concept | |||
| actually I don't think it's right to consider / an "equivalent" of div at all | 17:37 | ||
| they just both have "division" in their names | |||
| anyway, this note is meant for the future, I don't think it impacts the fate of the current behavior of div and mod that much | 17:44 | ||
|
17:48
Nemokosch joined
18:53
ds7832 joined
19:33
ds7832 left
19:34
ds7832 joined
19:44
Nemokosch left
19:47
ds7832 left
|
|||