Newest at the top
| 2025-02-07 10:19:30 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-02-07 10:19:25 +0100 | <tomsmeding> | a lot of understanding how to read (and fix) type errors from GHC comes down to honing your mental model of in what situations these diagnostics arise, and that mental model is distressingly associative (as opposed to logical) |
| 2025-02-07 10:18:13 +0100 | AlexZenon | (~alzenon@178.34.151.30) |
| 2025-02-07 10:17:22 +0100 | <tomsmeding> | dminuoso: you know, given the appearance of that GServant or what was it, I already had an inkling that it might be that |
| 2025-02-07 10:16:32 +0100 | Googulator | (~Googulato@81.183.235.203) |
| 2025-02-07 10:14:45 +0100 | akegalj | (~akegalj@89-172-213-142.adsl.net.t-com.hr) (Ping timeout: 268 seconds) |
| 2025-02-07 10:13:14 +0100 | AlexNoo | (~AlexNoo@5.139.233.186) (Ping timeout: 260 seconds) |
| 2025-02-07 10:13:00 +0100 | AlexZenon | (~alzenon@5.139.233.186) (Ping timeout: 276 seconds) |
| 2025-02-07 10:12:17 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-07 10:09:33 +0100 | AlexNoo_ | (~AlexNoo@178.34.151.30) |
| 2025-02-07 10:09:29 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-07 10:03:50 +0100 | sim590 | (~simon@24-122-69-233.resi.cgocable.ca) sim590 |
| 2025-02-07 10:01:44 +0100 | mcfrdy | (~mcfrdy@user/mcfrdy) mcfrdy |
| 2025-02-07 09:59:09 +0100 | <dminuoso> | It's *much* faster and can yield much better errors. |
| 2025-02-07 09:58:34 +0100 | <dminuoso> | At this point I've finally settled on an opinion: Servant while being a neat experiment is not worth the type trickery: TH is more suitable for the job. |
| 2025-02-07 09:56:00 +0100 | <dminuoso> | Ill try and condense this into an isolated reproducer without servant next week. |
| 2025-02-07 09:55:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 09:54:56 +0100 | <dminuoso> | I'm half-way convinced that this could be a GHC diagnostics bug. |
| 2025-02-07 09:54:26 +0100 | <dminuoso> | tomsmeding: By the way, the error was because I was missing a Generic instance. |
| 2025-02-07 09:49:15 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-07 09:48:45 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 246 seconds) |
| 2025-02-07 09:45:40 +0100 | dhil | (~dhil@2a0c:b381:5bf:3500:33f8:3d71:b2ae:2adc) dhil |
| 2025-02-07 09:39:02 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 09:37:34 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-07 09:34:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 09:33:09 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 09:32:13 +0100 | ensyde | (~ensyde@2601:5c6:c200:6dc0::9939) (Quit: WeeChat 4.5.1) |
| 2025-02-07 09:28:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-02-07 09:23:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 09:23:15 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-02-07 09:20:36 +0100 | ensyde | (~ensyde@2601:5c6:c200:6dc0::9939) ensyde |
| 2025-02-07 09:19:52 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
| 2025-02-07 09:19:16 +0100 | tnt2 | tnt1 |
| 2025-02-07 09:19:16 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 268 seconds) |
| 2025-02-07 09:17:34 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-02-07 09:17:34 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-07 09:14:55 +0100 | misterfish | (~misterfis@h239071.upc-h.chello.nl) misterfish |
| 2025-02-07 09:13:14 +0100 | <kqr> | Thanks |
| 2025-02-07 09:13:02 +0100 | <kqr> | This also helps explain why (const . const . const) f and (const . const . const . f) behaves the way they do! |
| 2025-02-07 09:12:38 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-07 09:12:36 +0100 | <kqr> | Since const f is really something like const f _ = f it will swallow a dummy argument before starting to apply f, whereas const . f first applies f and then swallows a dummy argument. Yeah, thinking of it that way helps. |
| 2025-02-07 09:11:36 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) |
| 2025-02-07 09:11:18 +0100 | euleritian | (~euleritia@dynamic-176-006-138-232.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-02-07 09:10:29 +0100 | <kqr> | Aah, I might be starting to get it! |
| 2025-02-07 09:08:07 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-07 09:01:49 +0100 | <mauke> | it's just where the dummy argument gets inserted |
| 2025-02-07 09:01:44 +0100 | chele | (~chele@user/chele) chele |
| 2025-02-07 09:01:37 +0100 | <mauke> | I don't see it as swapping, really |
| 2025-02-07 09:01:18 +0100 | <mauke> | and const . f :: a -> x -> b |
| 2025-02-07 09:01:07 +0100 | <mauke> | if f :: a -> b, then const f :: x -> a -> b |