Newest at the top
| 2025-03-12 06:06:58 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 272 seconds) |
| 2025-03-12 06:06:07 +0100 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-03-12 06:02:05 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-12 05:57:44 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 05:57:10 +0100 | jmcantrell | (~weechat@user/jmcantrell) (Quit: WeeChat 4.5.2) |
| 2025-03-12 05:56:26 +0100 | tusko | (uid478376@user/tusko) tusko |
| 2025-03-12 05:55:13 +0100 | <c_wraith> | yes. the solver always shrinks the problem with the default rules |
| 2025-03-12 05:55:04 +0100 | <EvanR> | so there's a way to use it semilogically |
| 2025-03-12 05:54:37 +0100 | <EvanR> | that being said, the type class system always terminates if you don't enable any dark magic pragmas right |
| 2025-03-12 05:53:29 +0100 | <c_wraith> | inconsistent logics are nice because they let you prove anything, and so does Haskell |
| 2025-03-12 05:52:52 +0100 | <EvanR> | falso 9.6 |
| 2025-03-12 05:52:19 +0100 | <c_wraith> | pfft. It's a logic, it's just not a consistent one. |
| 2025-03-12 05:52:02 +0100 | <EvanR> | when someone said haskell is not a logic they weren't kidding |
| 2025-03-12 05:50:36 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 276 seconds) |
| 2025-03-12 05:50:28 +0100 | <c_wraith> | I'm sure nothing bad could happen |
| 2025-03-12 05:49:58 +0100 | <EvanR> | now it's telling me the reduction stack size of 201 ran out, and instead of increasing it, to disable the check if I'm sure type checking will terminate |
| 2025-03-12 05:47:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-12 05:46:55 +0100 | <euouae> | it's like those no-fault waivers |
| 2025-03-12 05:46:53 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-03-12 05:46:19 +0100 | <EvanR> | lol |
| 2025-03-12 05:46:16 +0100 | <c_wraith> | you should be getting nervous. |
| 2025-03-12 05:45:59 +0100 | <EvanR> | ghci told me to enable IncoherentInstances |
| 2025-03-12 05:45:44 +0100 | <EvanR> | I continued to try to troll ghc with some terrible overlapping instances |
| 2025-03-12 05:44:34 +0100 | <c_wraith> | On one hand, that's why the Show1 class exists. On the other, you can do it with UndecidableInstances and StandaloneDeriving. |
| 2025-03-12 05:43:32 +0100 | <c_wraith> | And in that case, the constraint is definitely larger than the instance head. |
| 2025-03-12 05:43:15 +0100 | <c_wraith> | A common way to end up needing UndecidableInstances without MPTCs or Overlapping is stuff like Fix. `newtype Fix f = Fix (f (Fix f))`. Attempting the automatic Show instance for that ends up with the compiler trying to write something like `instance Show (f (Fix f)) => Show (Fix f) ...` |
| 2025-03-12 05:42:45 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 05:40:21 +0100 | <c_wraith> | when it was module level, it did just say "turn on this extension to allow this" |
| 2025-03-12 05:40:09 +0100 | <EvanR> | (and LANGUAGE OverlappingInstances is deprecated) |
| 2025-03-12 05:40:05 +0100 | <c_wraith> | I guess when overlapping was moved to a per-instance pragma, they decided not to advise turning it on |
| 2025-03-12 05:40:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 05:39:42 +0100 | <EvanR> | but at least doesn't tell me to turn it on xD |
| 2025-03-12 05:39:37 +0100 | <EvanR> | GHC rejects my code because of overlapping instances |
| 2025-03-12 05:39:23 +0100 | <EvanR> | I tried it |
| 2025-03-12 05:35:46 +0100 | <euouae> | oh I see |
| 2025-03-12 05:35:09 +0100 | <EvanR> | ok nvm that |
| 2025-03-12 05:34:51 +0100 | <c_wraith> | and that's when things get fragile |
| 2025-03-12 05:34:45 +0100 | <c_wraith> | So then ghc is going to tell you to allow overlapping |
| 2025-03-12 05:34:37 +0100 | <c_wraith> | yeah, that example would trigger it, but that's not a problem. The problem is that that instance overlaps everything |
| 2025-03-12 05:34:32 +0100 | <EvanR> | does the implied kind expected by the hypothetical Foo class make sense there |
| 2025-03-12 05:34:24 +0100 | synchromesh | (~john@2406:5a00:24cf:bb00:98ab:59f5:dcb3:c8fc) synchromesh |
| 2025-03-12 05:34:04 +0100 | <euouae> | but I'm assuming you're saying that the more important/encountered issue is overlapping instances |
| 2025-03-12 05:33:15 +0100 | synchromesh | (~john@2406:5a00:24cf:bb00:c559:e625:333a:3d27) (Read error: Connection reset by peer) |
| 2025-03-12 05:33:15 +0100 | <euouae> | perhaps if I did `instance Foo (F x) => Foo x where ...`? |
| 2025-03-12 05:32:56 +0100 | <euouae> | I wasn't sure in what situation I'd run into undecidability with instance declarations |
| 2025-03-12 05:31:23 +0100 | <c_wraith> | UndecidableInstances is basically always fine to turn on. It's when you do and then GHC tells you the next thing to do is turn on overlapping, you know you're doing something wrong. |
| 2025-03-12 05:30:14 +0100 | mange | (~user@user/mange) mange |
| 2025-03-12 05:29:05 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-03-12 05:28:51 +0100 | <EvanR> | (unless you do overlapping instances and god help you) |
| 2025-03-12 05:28:35 +0100 | <EvanR> | typeclasses aren't built to do the sort of "overriding" that you see in prototypal OOP. Your type either has a single instance for the class, or it doesn't. Not competing instances with priority |