2025/08/14

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 +0200chele(~chele@user/chele) (Remote host closed the connection)
2025-08-14 17:49:38 +0200AlexZenon(~alzenon@178.34.150.240)
2025-08-14 17:43:34 +0200trickard_(~trickard@cpe-86-98-47-163.wireline.com.au) (Ping timeout: 255 seconds)
2025-08-14 17:42:29 +0200trickard__(~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 +0200AlexZenon(~alzenon@178.34.150.240) (Ping timeout: 260 seconds)
2025-08-14 17:36:38 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.5.2)
2025-08-14 17:33:13 +0200tromp(~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 +0200werneta(~werneta@syn-071-083-160-242.res.spectrum.com) (Ping timeout: 255 seconds)
2025-08-14 17:30:50 +0200AlexZenon(~alzenon@178.34.150.240)
2025-08-14 17:30:49 +0200jbalint(~jbalint@2600:6c44:117f:e98a:40bb:52ad:62b8:5122)
2025-08-14 17:27:28 +0200trickard_(~trickard@cpe-86-98-47-163.wireline.com.au)
2025-08-14 17:27:14 +0200trickard_(~trickard@cpe-86-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-08-14 17:26:58 +0200jbalint_(~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 +0200amadaluzia(~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 +0200machinedgod(~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod
2025-08-14 17:24:42 +0200ashkan81(~ashkan81@147.161.173.107)
2025-08-14 17:24:07 +0200amadaluzia(~amadaluzi@user/amadaluzia) (Quit: You)
2025-08-14 17:20:38 +0200tromp(~textual@2001:1c00:3487:1b00:ad02:3d09:c5b5:9908)
2025-08-14 17:18:49 +0200ttybitnik(~ttybitnik@user/wolper) (Quit: Fading out...)
2025-08-14 17:18:37 +0200amadaluzia(~amadaluzi@user/amadaluzia) amadaluzia
2025-08-14 17:18:37 +0200AlexZenon(~alzenon@178.34.150.240) (Ping timeout: 260 seconds)
2025-08-14 17:17:44 +0200amadaluzia(~amadaluzi@user/amadaluzia) (Ping timeout: 260 seconds)
2025-08-14 17:11:08 +0200fp(~Thunderbi@2001:708:150:10::72df) (Ping timeout: 272 seconds)
2025-08-14 17:10:18 +0200AlexZenon(~alzenon@178.34.150.240)
2025-08-14 17:02:55 +0200vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2025-08-14 17:02:41 +0200tromp(~textual@2001:1c00:3487:1b00:ad02:3d09:c5b5:9908) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-08-14 16:58:38 +0200trickard_(~trickard@cpe-86-98-47-163.wireline.com.au)
2025-08-14 16:55:52 +0200vanishingideal(~vanishing@user/vanishingideal) (Ping timeout: 252 seconds)
2025-08-14 16:52:31 +0200amadaluzia(~amadaluzi@user/amadaluzia) amadaluzia
2025-08-14 16:51:42 +0200trickard_(~trickard@cpe-86-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-08-14 16:51:08 +0200humasect(~humasect@dyn-192-249-132-90.nexicom.net) humasect
2025-08-14 16:48:34 +0200trickard_(~trickard@cpe-86-98-47-163.wireline.com.au)
2025-08-14 16:48:10 +0200trickard_(~trickard@cpe-86-98-47-163.wireline.com.au) (Ping timeout: 252 seconds)
2025-08-14 16:46:38 +0200AlexZenon(~alzenon@178.34.150.240) (Ping timeout: 245 seconds)
2025-08-14 16:45:35 +0200ft(~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 +0200AlexZenon(~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