Logs: liberachat/#haskell
| 2025-09-10 23:47:23 | → | acidjnk joins (~acidjnk@p200300d6e717192649d3cadc2eaa05e5.dip0.t-ipconnect.de) |
| 2025-09-10 23:53:10 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-09-10 23:58:29 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-09-11 00:01:06 | → | mikess joins (~sam@user/mikess) |
| 2025-09-11 00:02:14 | × | acidjnk quits (~acidjnk@p200300d6e717192649d3cadc2eaa05e5.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2025-09-11 00:03:19 | → | itaipu joins (~itaipu@168.121.97.28) |
| 2025-09-11 00:04:57 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 2025-09-11 00:05:04 | → | Lord_of_Life joins (~Lord@user/lord-of-life/x-2819915) |
| 2025-09-11 00:08:59 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-09-11 00:10:39 | × | segfaultfizzbuzz quits (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) (Ping timeout: 250 seconds) |
| 2025-09-11 00:14:05 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-09-11 00:15:16 | × | Lycurgus quits (~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org )) |
| 2025-09-11 00:21:10 | × | otto_s quits (~user@p5b0442fa.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2025-09-11 00:22:49 | → | otto_s joins (~user@p5de2f433.dip0.t-ipconnect.de) |
| 2025-09-11 00:24:18 | → | robobub joins (uid248673@id-248673.uxbridge.irccloud.com) |
| 2025-09-11 00:24:46 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-09-11 00:31:29 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 258 seconds) |
| 2025-09-11 00:31:42 | → | mange joins (~mange@user/mange) |
| 2025-09-11 00:35:25 | → | karenw_ joins (~karenw@user/karenw) |
| 2025-09-11 00:36:19 | Axma39609 | is now known as Axman6 |
| 2025-09-11 00:37:43 | × | karenw quits (~karenw@user/karenw) (Ping timeout: 265 seconds) |
| 2025-09-11 00:38:54 | → | szkl joins (uid110435@id-110435.uxbridge.irccloud.com) |
| 2025-09-11 00:40:37 | × | xff0x quits (~xff0x@2405:6580:b080:900:c68c:683e:9c65:6f0a) (Ping timeout: 265 seconds) |
| 2025-09-11 00:41:27 | × | mikess quits (~sam@user/mikess) (Ping timeout: 258 seconds) |
| 2025-09-11 00:46:03 | → | jmcantrell_ joins (~weechat@user/jmcantrell) |
| 2025-09-11 00:57:07 | → | segfaultfizzbuzz joins (~segfaultf@23-93-74-222.fiber.dynamic.sonic.net) |
| 2025-09-11 00:58:17 | × | chromoblob quits (~chromoblo@user/chromob1ot1c) (Remote host closed the connection) |
| 2025-09-11 01:13:01 | × | jmcantrell_ quits (~weechat@user/jmcantrell) (Quit: WeeChat 4.7.1) |
| 2025-09-11 01:18:38 | × | vetkat quits (~vetkat@user/vetkat) (Ping timeout: 258 seconds) |
| 2025-09-11 01:19:22 | → | vetkat joins (~vetkat@user/vetkat) |
| 2025-09-11 01:22:25 | → | chromoblob joins (~chromoblo@user/chromob1ot1c) |
| 2025-09-11 01:34:15 | → | EvanR joins (~EvanR@user/evanr) |
| 2025-09-11 01:40:22 | → | xff0x joins (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-09-11 01:42:03 | <L29Ah> | https://bpa.st/RAGA how can this sad state of affairs be helped, except perhaps putting every record type in its own module? |
| 2025-09-11 01:56:09 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-09-11 01:59:27 | × | karenw_ quits (~karenw@user/karenw) (Quit: Deep into that darkness peering...) |
| 2025-09-11 02:00:54 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-09-11 02:02:38 | <pavonia> | Wasn't there an extension for that purpose? |
| 2025-09-11 02:03:00 | <jackdk> | Try enabling `{-# LANGUAGE DisambiguateRecordFields #-}` |
| 2025-09-11 02:03:26 | <pavonia> | Yeah https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/disambiguate_record_fields.html |
| 2025-09-11 02:07:21 | <L29Ah> | jackdk: i did |
| 2025-09-11 02:07:33 | <L29Ah> | this is the result |
| 2025-09-11 02:07:45 | <jackdk> | It might be `DuplicateRecordFields` that you need |
| 2025-09-11 02:07:49 | <L29Ah> | jackdk: i did |
| 2025-09-11 02:08:28 | <pavonia> | The ambiguity cannot be resolved in all cases, adding type annotations should help in those cases |
| 2025-09-11 02:08:31 | <L29Ah> | apparently it can't do anything when it doesn't see the constructor right at the record mutation |
| 2025-09-11 02:08:31 | <jackdk> | Then, respectfully, why did you not open with this information? |
| 2025-09-11 02:08:40 | <L29Ah> | i added the type annotation as you can see |
| 2025-09-11 02:08:59 | <Leary> | I don't believe there's any extension that allows this out-of-the-box. Technically, I think you can do it with OverloadedRecordUpdate and some boilerplate, but I wouldn't say it's better than the alternative. |
| 2025-09-11 02:09:02 | <L29Ah> | jackdk: because i thought it is obvious |
| 2025-09-11 02:09:41 | <L29Ah> | Leary: the current boilerplate is crazy and seems like it will go on like that for a while -- https://gitlab.haskell.org/ghc/ghc/-/issues/16232 |
| 2025-09-11 02:09:58 | <jackdk> | I just noticed the record update is applied to the `def` and then you do the type application. You may have luck with `def @LlamaRequest` because then GHC may figure out the type of the record being updated |
| 2025-09-11 02:10:41 | <glguy> | that isn't enough (I tried earlier) |
| 2025-09-11 02:11:31 | <glguy> | in the case the work around is to use the named default value for that type and avoid def |
| 2025-09-11 02:11:56 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-09-11 02:13:17 | <L29Ah> | glguy: named default value doesn't seem to change anything |
| 2025-09-11 02:13:34 | <L29Ah> | deff :: LlamaRequest |
| 2025-09-11 02:13:34 | <L29Ah> | defined at the top level, that is |
| 2025-09-11 02:14:03 | <glguy> | Oh, I forgot which issue you were running into. sorry. your original separate module solution seems best if you have to use duplicate record fields |
| 2025-09-11 02:15:19 | <L29Ah> | i don't strictly have to but aeson's generics work the best without mangling the field names |
| 2025-09-11 02:16:46 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-09-11 02:17:25 | <jackdk> | L29Ah: GHC 9.8.4 accepts this code but warns that type-directed record updates will be eventually deprecated and removed. The key difference is using a type annotation on `def` instead of a type application (either before or after the record update) https://www.irccloud.com/pastebin/kc8TPwKu/Encode.hs |
| 2025-09-11 02:18:41 | <L29Ah> | jackdk: it is already removed in 9.12 IIRC |
| 2025-09-11 02:18:49 | <glguy> | that file loads in 9.12 |
| 2025-09-11 02:19:22 | <L29Ah> | nvm thanks |
| 2025-09-11 02:19:31 | <glguy> | but it doesn't seem great to rely on it sticking around in any case |
| 2025-09-11 02:20:41 | <L29Ah> | i have a gut feeling that it won't be purged before 16232 gets in |
| 2025-09-11 02:22:22 | <L29Ah> | https://gitlab.haskell.org/ghc/ghc/-/issues/25075#note_576241 |
| 2025-09-11 02:23:55 | <L29Ah> | https://github.com/ghc-proposals/ghc-proposals/pull/366 me pushe dislike so very hard!! |
| 2025-09-11 02:23:59 | <jackdk> | https://github.com/ghc-proposals/ghc-proposals/pull/537#issuecomment-1327646670 there is an open proposal around having some form of type-signature-directed record updates stick around |
| 2025-09-11 02:26:00 | <jackdk> | Remark: I generally recommend against using `class Default` because it's got no laws, and so it's very difficult to write a function that usefully generalises over `Default` instances, which to me is one of the two main points of having a typeclass (the other being to have GHC build a function in a type-directed manner, which also doesn't apply here). |
| 2025-09-11 02:26:54 | <jackdk> | I tend to use generic-lens or generic-optics to do record updates unless I'm building a library where I need to not blow out the dependency footprint, which can look pretty nice with OverloadedLabels |
| 2025-09-11 02:27:43 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-09-11 02:32:45 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-09-11 02:33:52 | <geekosaur> | Default can also bite you with unexpected types having Default instances |
| 2025-09-11 02:34:06 | <geekosaur> | xmonad has already had a bug caused by it |
| 2025-09-11 02:36:37 | <L29Ah> | could be argued about Monoid/mempty likewise |
| 2025-09-11 02:37:11 | <L29Ah> | i try not to forget toplevel function signatures and decomposition to help with that |
| 2025-09-11 02:38:57 | <jackdk> | Hard disagree re: Monoid because `mempty` has sensible behavior because of the laws that describe its interactions with `(<>)` |
| 2025-09-11 02:39:15 | <geekosaur> | ^ |
| 2025-09-11 02:39:38 | <geekosaur> | Default just does whatever whoever added the instance wanted… but defaults depend on context |
| 2025-09-11 02:40:06 | <geekosaur> | like, arguments could be made that the Default instance for Int should be 1 (think the addition vs. multiplication divide) |
| 2025-09-11 02:40:28 | <monochrom> | I just cite the PHP example. Call it a strawman or anecdotal or whatever. There is a time type in PHP, then someone decreed that it has a default value and it is 0. Fortunately, someone else has the sanity to point out what's wrong with it. |
| 2025-09-11 02:40:34 | <L29Ah> | oh Int has Default, great |
| 2025-09-11 02:41:06 | <jackdk> | https://hackage.haskell.org/package/acme-default has much better instances |
| 2025-09-11 02:41:11 | <geekosaur> | (->) e has a default |
| 2025-09-11 02:41:20 | <geekosaur> | (which is what bit us) |
| 2025-09-11 02:41:43 | <geekosaur> | _lots_ of things have defaults. are they useful in all cases? not a chance |
| 2025-09-11 02:43:02 | <monochrom> | I am OK with Default as long as you don't inflict your personalized idea of "default Int" on me. |
| 2025-09-11 02:43:27 | <monochrom> | But then that's just another way to say that I accept Monoid not Default. |
| 2025-09-11 02:43:30 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-09-11 02:44:00 | <monochrom> | (Int, (+)) has a default. (Int, (*)) has a default. There are others. Int alone has no default. |
| 2025-09-11 02:44:01 | <geekosaur> | there's no way to not inflict a personalized idea if it's a typeclass |
| 2025-09-11 02:44:51 | <geekosaur> | the typeclass police should arrest Default |
| 2025-09-11 02:45:28 | <mauke> | (->) e had a default |
| 2025-09-11 02:46:26 | <monochrom> | Actually, isn't (->)e the wrong kind for Default? |
| 2025-09-11 02:46:53 | <mauke> | implied (Default a) => Default ((->) e a) |
| 2025-09-11 02:47:00 | <monochrom> | Oh, that. |
| 2025-09-11 02:47:03 | <dibblego> | every time I look at Default, it is worse than my imagination approximates, but I assume it is ((->) e e) |
| 2025-09-11 02:47:09 | <dibblego> | oh |
All times are in UTC.