Newest at the top
| 2025-02-07 10:22:42 +0100 | akegalj | (~akegalj@141-136-207-93.dsl.iskon.hr) |
| 2025-02-07 10:22:29 +0100 | <dminuoso> | tomsmeding: If this was some missing instance of some obscure deeply hidden GServerantSomething class that would have been obvious. |
| 2025-02-07 10:22:22 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-02-07 10:21:31 +0100 | <tomsmeding> | probably because essentially any time I've seen G* stuff in type errors, it was because the generics stuff was wrong, not because something else was :p |
| 2025-02-07 10:21:15 +0100 | <hololeap> | I'm looking for any comments on ways this code can be improved: https://bpa.st/FTCA |
| 2025-02-07 10:21:14 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-07 10:21:11 +0100 | sa | (sid1055@id-1055.tinside.irccloud.com) (Ping timeout: 252 seconds) |
| 2025-02-07 10:21:00 +0100 | <tomsmeding> | okay let me be more precise: I didn't intuit that _you_ were missing a Generic instance. Just that it was something with GServant not reducing due to (I didn't think this far) |
| 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) |