Newest at the top
| 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 |
| 2025-03-12 05:27:16 +0100 | <EvanR> | it leads to overlapping instances |
| 2025-03-12 05:27:03 +0100 | <EvanR> | then ekmett gets to that in the response |
| 2025-03-12 05:26:51 +0100 | <EvanR> | the first thing I thought was "for some reason, this idea of default implementations that work for everything with a certain typeclass instance is frowned upon" and couldn't remember the reason |
| 2025-03-12 05:26:13 +0100 | infinity0 | (~infinity0@pwned.gg) (Ping timeout: 245 seconds) |
| 2025-03-12 05:24:40 +0100 | <euouae> | but at the same time it's fine because of the functional dependency | m -> s in the definition of MonadState in mtl |
| 2025-03-12 05:24:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 05:24:19 +0100 | <euouae> | what I gathered from the reddit post is that the 's' is not getting smaller and that is the issue |
| 2025-03-12 05:23:33 +0100 | <EvanR> | which these smaller conditions guarantee |
| 2025-03-12 05:23:16 +0100 | <EvanR> | it's really nice when the compiler knows that it will finish and not enter into an infinite loop |
| 2025-03-12 05:22:58 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-03-12 05:22:52 +0100 | <EvanR> | The constraint ‘Monad (t n)’ is no smaller than the instance head (Use UndecidableInstances to permit this) |
| 2025-03-12 05:18:43 +0100 | <euouae> | This thread <https://www.reddit.com/r/haskell/comments/5zjwym/when_is_undecidableinstances_okay_to_use/> has good info on UndecidableInstances, the other two were easier to understand |
| 2025-03-12 05:13:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-12 05:06:58 +0100 | euouae | (~euouae@user/euouae) euouae |
| 2025-03-12 05:06:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 05:01:25 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |