Newest at the top
| 2025-01-10 13:09:01 +0100 | <mari47944> | hm not sure whether that feature requires a different module system or a different binary interface or both |
| 2025-01-10 13:08:41 +0100 | l_k_ | (~student@85.172.110.63) |
| 2025-01-10 13:08:18 +0100 | <hellwolf> | some referred to it as ML module maybe |
| 2025-01-10 13:08:18 +0100 | <[exa]> | ah, the backpacky stuff |
| 2025-01-10 13:08:06 +0100 | <hellwolf> | there is a specific name to it |
| 2025-01-10 13:08:02 +0100 | <hellwolf> | I think people wanted a module where you can swap implementations after distribution |
| 2025-01-10 13:07:55 +0100 | <[exa]> | heretics! |
| 2025-01-10 13:07:51 +0100 | l_k | (~student@85.172.110.73) |
| 2025-01-10 13:07:48 +0100 | <mari47944> | many consider it improvable |
| 2025-01-10 13:07:20 +0100 | <[exa]> | hellwolf: "module system" we don't have one? |
| 2025-01-10 13:03:49 +0100 | <hellwolf> | nevermind. |
| 2025-01-10 13:03:31 +0100 | <hellwolf> | hmm, no, even with orphaned instance you can't swap it out later, since compiling the library would require such type class exist. |
| 2025-01-10 13:01:41 +0100 | <hellwolf> | Am I crazy to envision that type class and type families (perhaps type family fundeps) too could achieve the module system that we deserve? Though, perhaps packaging around it would be needed to make it more close to module system, instead of boilerplated type classes. |
| 2025-01-10 12:57:23 +0100 | <mari47944> | i mean swapping technically fits into "fearless refactoring" ^^ |
| 2025-01-10 12:56:35 +0100 | <merijn> | [exa]: Then if you don't wanna swap the arguments the closest you can get is newtype shenanigans |
| 2025-01-10 12:56:07 +0100 | <[exa]> | `ala` does something similar for lensy stuff |
| 2025-01-10 12:55:45 +0100 | <[exa]> | mari47944: no I don't think that exists |
| 2025-01-10 12:55:42 +0100 | mari47944 | forgot that syntax again... |
| 2025-01-10 12:55:27 +0100 | <mari47944> | %:t fmapAla |
| 2025-01-10 12:55:27 +0100 | <[exa]> | merijn: yeah except it's not super functorial in the second arg, so the bifunctor would lie a lot |
| 2025-01-10 12:54:42 +0100 | <merijn> | [exa]: That, or a newtype wrapper |
| 2025-01-10 12:54:34 +0100 | <merijn> | [exa]: Then you can do functory things in both :p |
| 2025-01-10 12:54:17 +0100 | <merijn> | [exa]: Bifunactor? :) |
| 2025-01-10 12:54:03 +0100 | <[exa]> | ok let's see |
| 2025-01-10 12:53:51 +0100 | <mari47944> | yeah, nest it |
| 2025-01-10 12:53:49 +0100 | <merijn> | s/alinab/alist |
| 2025-01-10 12:53:45 +0100 | [exa] | contemplates fmapAla |
| 2025-01-10 12:53:41 +0100 | <merijn> | alinab: Keep in mind that many papers like these are incredibly concisely written and truly grasping them can take a few reads to unpack |
| 2025-01-10 12:53:22 +0100 | <[exa]> | "wrap" basically a newtype wrapper that would have to inherit all other instances too, right? |
| 2025-01-10 12:50:07 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-10 12:50:04 +0100 | <mari47944> | reorder or wrap it, not aware of anything better |
| 2025-01-10 12:49:23 +0100 | sprotte24 | (~sprotte24@p200300d16f053e00ccd1db6c99978e80.dip0.t-ipconnect.de) (Client Quit) |
| 2025-01-10 12:48:29 +0100 | sprotte24 | (~sprotte24@p200300d16f053e00ccd1db6c99978e80.dip0.t-ipconnect.de) |
| 2025-01-10 12:47:57 +0100 | <[exa]> | (background: I didn't write that type but it screams for a functor instance) |
| 2025-01-10 12:47:02 +0100 | <hellwolf> | Leary: thanks! |
| 2025-01-10 12:46:40 +0100 | <[exa]> | if I have a datatype with 2 arguments, say `X a b`, and I want to make a Functor instance so that the thing is functorial in the `a` variable (i.e, not the last one as usual), is there some kind of adaptor that would allow me to fit this somewhat nicely, or do I always have to reorder the type arguments? |
| 2025-01-10 12:46:09 +0100 | alist | (~alist@user/alist) (Quit: Leaving) |
| 2025-01-10 12:41:52 +0100 | TMA | (tma@twin.jikos.cz) (Ping timeout: 252 seconds) |
| 2025-01-10 12:41:10 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-10 12:34:01 +0100 | todi1 | todi |
| 2025-01-10 12:28:19 +0100 | notzmv | (~umar@user/notzmv) (Ping timeout: 245 seconds) |
| 2025-01-10 12:27:51 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-10 12:27:38 +0100 | <Leary> | (taking `D` as a type unrelated to the constructor) |
| 2025-01-10 12:26:34 +0100 | <Leary> | If you wish, you can encode the existential with `[forall r. (forall a. D a -> r) -> r]`, but I don't really think that's an improvement. |
| 2025-01-10 12:25:23 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-01-10 12:25:16 +0100 | <Leary> | hellwolf: You should regard the syntax `data AnyD = forall a. D a` as a mistake and not be misled by it. One list has a universally quantified type, the other existentially---they're very different. |
| 2025-01-10 12:24:09 +0100 | CiaoSen | (~Jura@2a05:5800:2e7:b00:ca4b:d6ff:fec1:99da) (Ping timeout: 276 seconds) |
| 2025-01-10 12:21:07 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-10 12:20:51 +0100 | g00gler | (uid125351@id-125351.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-10 12:19:32 +0100 | alist | (~alist@user/alist) alist |