Newest at the top
| 2026-04-03 20:52:21 +0000 | <geekosaur> | In the case of gcc a lot of it is older sources and the rest is things known to trip unsuspecting programmers |
| 2026-04-03 20:51:19 +0000 | <tomsmeding> | ( https://downloads.haskell.org/ghc/latest/docs/users_guide/using-warnings.html#ghc-flag-Wdefault ) |
| 2026-04-03 20:51:15 +0000 | <tomsmeding> | dolio: would -Wdefault do? Or is perhaps -Winaccessible-code too much? |
| 2026-04-03 20:49:04 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-04-03 20:48:32 +0000 | <Leary> | Global coherence and modularity are at odds; responsibility for their coexistence should fall to the language or packaging system. I can't blame 'aeson' for not wanting to write a bunch of orphans---they really shouldn't have to. Hell, they shouldn't even be /allowed/ to. |
| 2026-04-03 20:47:33 +0000 | <dolio> | I don't do much C, so I don't know about gcc's choices. |
| 2026-04-03 20:47:16 +0000 | <dolio> | GHC. |
| 2026-04-03 20:47:06 +0000 | <tomsmeding> | dolio: you mean GHC's -Wall, or also gcc's -Wall? |
| 2026-04-03 20:46:47 +0000 | <dolio> | It'd have to be trimmed way back, at least. |
| 2026-04-03 20:44:52 +0000 | <dolio> | I'm not sure any -Wall would be something that I'd endorse, because there are just too many people eager to follow arbitrary coding conventions that trade one error for another, at least in Haskell. |
| 2026-04-03 20:44:06 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-04-03 20:43:45 +0000 | <tomsmeding> | -Wall not having all warnings, just the generally important ones, is a historical naming error that we're unlikely to be correcting now |
| 2026-04-03 20:42:56 +0000 | <dolio> | It seems odd to not want all the warnings in -Wall, even though it still doesn't have all the warnings. |
| 2026-04-03 20:38:47 +0000 | <geekosaur> | and I have in fact heard people respond to your complaint with "so why is it in `-Wall`?" |
| 2026-04-03 20:38:24 +0000 | <geekosaur> | part of the problem there is people being trained by gcc/g++ where it's usually a good idea |
| 2026-04-03 20:36:36 +0000 | takuan | (~takuan@d8D86B9E9.access.telenet.be) (Ping timeout: 255 seconds) |
| 2026-04-03 20:35:28 +0000 | <dolio> | Just in general. |
| 2026-04-03 20:35:16 +0000 | <dolio> | Part of the problem is people unthinkinly obeying stuff in -Wall. |
| 2026-04-03 20:34:14 +0000 | <tomsmeding> | good, question resolved, it's aeson's problem :p |
| 2026-04-03 20:33:59 +0000 | <tomsmeding> | agreed |
| 2026-04-03 20:33:52 +0000 | <dolio> | And the rule should mean that random other idiots shouldn't be writing orphan instances for aeson. |
| 2026-04-03 20:33:36 +0000 | <dolio> | It seems like it should be okay for aeson to separate a canonical package out with orphan quick check instances. |
| 2026-04-03 20:33:26 +0000 | <tomsmeding> | but yeah, here I'm really at a loss why there isn't `aeson` and then `aeson-quickcheck` which gives the Arbitrary instances, apart from blowing up the number of tiny packages on Hackage |
| 2026-04-03 20:33:19 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-04-03 20:32:47 +0000 | <tomsmeding> | (which is conventionally weakened to at least "no orphan instances in libraries", because in leaf applications they don't really hurt) |
| 2026-04-03 20:32:44 +0000 | <geekosaur> | I feel like it should be possible to declare exceptions |
| 2026-04-03 20:32:25 +0000 | <dolio> | I don't. |
| 2026-04-03 20:32:14 +0000 | <tomsmeding> | well, GHC's, if you consider GHC's warnings rules |
| 2026-04-03 20:31:50 +0000 | <dolio> | Whose rule is the no orphans rule? |
| 2026-04-03 20:30:38 +0000 | <tomsmeding> | the no-orphans rule understandable for soundness, but it has so many bad effects on a package ecosystem |
| 2026-04-03 20:30:09 +0000 | <tomsmeding> | answer: aeson wants to provide Arbitrary instances for stuff |
| 2026-04-03 20:29:47 +0000 | <tomsmeding> | there's a whole discussion there but I feel like it all comes down to the problem it always comes down to: why the f*** does aeson even depend on quickcheck |
| 2026-04-03 20:29:20 +0000 | <tomsmeding> | On the haskell-cafe mailing list there's a remark that aeson doesn't seem to be updated, and that its bound on QuickCheck needs to be bumped; aeson maintainers in turn complain that QuickCheck maintainers have strange views API stability, resulting in aeson not being able to upgrade to newest QuickCheck while keeping aeson's API stability views |
| 2026-04-03 20:28:19 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-04-03 20:17:15 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2026-04-03 20:11:32 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-04-03 20:07:21 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2026-04-03 20:03:56 +0000 | Digitteknohippie | (~user@user/digit) Digit |
| 2026-04-03 20:03:55 +0000 | Digit | (~user@user/digit) (Ping timeout: 245 seconds) |
| 2026-04-03 20:02:11 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-04-03 20:01:21 +0000 | jmcantrell_ | (~weechat@user/jmcantrell) jmcantrell |
| 2026-04-03 19:58:32 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2026-04-03 19:57:43 +0000 | slomp | (~slomp@47-158-212-88.lsan.ca.frontiernet.net) |
| 2026-04-03 19:56:58 +0000 | Lord_of_Life_ | Lord_of_Life |
| 2026-04-03 19:54:55 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 264 seconds) |
| 2026-04-03 19:54:05 +0000 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-04-03 19:53:33 +0000 | ncf | (~ncf@monade.li) ncf |
| 2026-04-03 19:51:12 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-04-03 19:46:28 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-04-03 19:44:23 +0000 | ncf | ncf- |