Newest at the top
| 2025-01-10 13:17:12 +0100 | <hellwolf> | Type theory people will laugh at our enthusiasm. |
| 2025-01-10 13:15:57 +0100 | l_k_ | (~student@85.172.110.63) (Ping timeout: 246 seconds) |
| 2025-01-10 13:14:36 +0100 | l__k | (~student@85.172.110.137) |
| 2025-01-10 13:13:01 +0100 | l_k | (~student@217.107.126.75) |
| 2025-01-10 13:12:44 +0100 | l_k | (~student@85.172.110.73) (Ping timeout: 264 seconds) |
| 2025-01-10 13:10:46 +0100 | l__k | (~student@217.107.126.148) (Ping timeout: 252 seconds) |
| 2025-01-10 13:10:04 +0100 | <[exa]> | module-level forall, module monomorphization, yay, gogogo! |
| 2025-01-10 13:09:38 +0100 | <hellwolf> | so there is room just to change how things are built |
| 2025-01-10 13:09:31 +0100 | <hellwolf> | we don't usually distribute libraries binary form |
| 2025-01-10 13:09:23 +0100 | <hellwolf> | perhaps just a different build mechanism |
| 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 |