Newest at the top
2025-08-14 17:54:53 +0200 | <dolio> | Like, you would not be able to write `foo :: (MonadReader a m, MonadReader b m) => a -> m b ; foo x = pure x` |
2025-08-14 17:54:01 +0200 | <dolio> | I don't know if things have changed in this regard, but it used to be the case that they would not work quite the same. |
2025-08-14 17:50:33 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
2025-08-14 17:49:38 +0200 | AlexZenon | (~alzenon@178.34.150.240) |
2025-08-14 17:43:34 +0200 | trickard_ | (~trickard@cpe-86-98-47-163.wireline.com.au) (Ping timeout: 255 seconds) |
2025-08-14 17:42:29 +0200 | trickard__ | (~trickard@cpe-88-98-47-163.wireline.com.au) |
2025-08-14 17:40:15 +0200 | <ncf> | another way to say this is that the constraint is equivalent to (MonadReader a m, a ~ b) |
2025-08-14 17:39:02 +0200 | AlexZenon | (~alzenon@178.34.150.240) (Ping timeout: 260 seconds) |
2025-08-14 17:36:38 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.5.2) |
2025-08-14 17:33:13 +0200 | tromp | (~textual@2001:1c00:3487:1b00:ad02:3d09:c5b5:9908) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2025-08-14 17:31:53 +0200 | <ashkan81> | Actually got my answer from Claude: in case `a ~ b` this can be satisfied so ghc compiles this but if you actually try to call it (I haven't yet) in a way that can't satisfy the constraint, then it complains. Makes sense +1 |
2025-08-14 17:31:52 +0200 | werneta | (~werneta@syn-071-083-160-242.res.spectrum.com) (Ping timeout: 255 seconds) |
2025-08-14 17:30:50 +0200 | AlexZenon | (~alzenon@178.34.150.240) |
2025-08-14 17:30:49 +0200 | jbalint | (~jbalint@2600:6c44:117f:e98a:40bb:52ad:62b8:5122) |
2025-08-14 17:27:28 +0200 | trickard_ | (~trickard@cpe-86-98-47-163.wireline.com.au) |
2025-08-14 17:27:14 +0200 | trickard_ | (~trickard@cpe-86-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
2025-08-14 17:26:58 +0200 | jbalint_ | (~jbalint@syn-071-090-116-115.res.spectrum.com) (Ping timeout: 240 seconds) |
2025-08-14 17:26:58 +0200 | <ashkan81> | Looks like my ghc-9.6.7 is more than happy to compile this (to me) impossible constraint and even run the code. I'm wondering what am I missing here ... |
2025-08-14 17:26:25 +0200 | amadaluzia | (~amadaluzi@user/amadaluzia) amadaluzia |
2025-08-14 17:25:32 +0200 | <ashkan81> | Hello everyone. Shouldn't this be impossible : `instance (MonadReader a m, MonadReader b m) => ... ` due to `m -> r` in `MonadReader` ? |
2025-08-14 17:25:20 +0200 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod |
2025-08-14 17:24:42 +0200 | ashkan81 | (~ashkan81@147.161.173.107) |
2025-08-14 17:24:07 +0200 | amadaluzia | (~amadaluzi@user/amadaluzia) (Quit: You) |
2025-08-14 17:20:38 +0200 | tromp | (~textual@2001:1c00:3487:1b00:ad02:3d09:c5b5:9908) |
2025-08-14 17:18:49 +0200 | ttybitnik | (~ttybitnik@user/wolper) (Quit: Fading out...) |
2025-08-14 17:18:37 +0200 | amadaluzia | (~amadaluzi@user/amadaluzia) amadaluzia |
2025-08-14 17:18:37 +0200 | AlexZenon | (~alzenon@178.34.150.240) (Ping timeout: 260 seconds) |
2025-08-14 17:17:44 +0200 | amadaluzia | (~amadaluzi@user/amadaluzia) (Ping timeout: 260 seconds) |
2025-08-14 17:11:08 +0200 | fp | (~Thunderbi@2001:708:150:10::72df) (Ping timeout: 272 seconds) |
2025-08-14 17:10:18 +0200 | AlexZenon | (~alzenon@178.34.150.240) |
2025-08-14 17:02:55 +0200 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
2025-08-14 17:02:41 +0200 | tromp | (~textual@2001:1c00:3487:1b00:ad02:3d09:c5b5:9908) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2025-08-14 16:58:38 +0200 | trickard_ | (~trickard@cpe-86-98-47-163.wireline.com.au) |
2025-08-14 16:55:52 +0200 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 252 seconds) |
2025-08-14 16:52:31 +0200 | amadaluzia | (~amadaluzi@user/amadaluzia) amadaluzia |
2025-08-14 16:51:42 +0200 | trickard_ | (~trickard@cpe-86-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
2025-08-14 16:51:08 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
2025-08-14 16:48:34 +0200 | trickard_ | (~trickard@cpe-86-98-47-163.wireline.com.au) |
2025-08-14 16:48:10 +0200 | trickard_ | (~trickard@cpe-86-98-47-163.wireline.com.au) (Ping timeout: 252 seconds) |
2025-08-14 16:46:38 +0200 | AlexZenon | (~alzenon@178.34.150.240) (Ping timeout: 245 seconds) |
2025-08-14 16:45:35 +0200 | ft | (~ft@p508dba54.dip0.t-ipconnect.de) ft |
2025-08-14 16:38:26 +0200 | <int-e> | tricky |
2025-08-14 16:38:23 +0200 | <int-e> | Yeah I guess if all your constraints are ordinary typeclasses then the open nature of those saves you from having to unify anything... |
2025-08-14 16:35:04 +0200 | <ncf> | (which i guess is the quintessential GADT) |
2025-08-14 16:34:25 +0200 | <ncf> | like the source of undecidability here is the equality constraint |
2025-08-14 16:33:07 +0200 | <ncf> | oh yeah i'm just not sure i would call that an existential |
2025-08-14 16:32:48 +0200 | <int-e> | You may still be right... |
2025-08-14 16:31:29 +0200 | <int-e> | data Eq a b where CEq :: a ~ b => Eq gives you an arbitrary unification problem depending on what a and b are when matching CEq, no? |
2025-08-14 16:30:05 +0200 | AlexZenon | (~alzenon@178.34.150.240) |
2025-08-14 16:28:57 +0200 | <ncf> | are existentials really problematic already? i don't immediately see how they could lead to undecidable unification problems |