Newest at the top
| 2026-01-18 00:29:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-01-18 00:28:07 +0100 | <haskellbridge> | <Man of Letters (Mikolaj)> some of the existential types arise naturally from AST GADTs (I have multiple interpreters of deeply embedded DLS in the implementation) |
| 2026-01-18 00:27:55 +0100 | troydm | (~troydm@user/troydm) troydm |
| 2026-01-18 00:25:34 +0100 | <haskellbridge> | <Man of Letters (Mikolaj)> Leary: where can I see an example of something like that? |
| 2026-01-18 00:24:53 +0100 | ethantwardy | (~user@user/ethantwardy) ethantwardy |
| 2026-01-18 00:24:38 +0100 | <Leary> | Man of Letters (Mikolaj): Re monomorphising, I see, that's a bit unfortunate. You can perhaps get rid of those existentials by using suitable heterogeneous types instead. |
| 2026-01-18 00:24:38 +0100 | <EvanR> | this might not apply exactly, I'm not sure I totally understand the situation |
| 2026-01-18 00:24:20 +0100 | <EvanR> | let f = makeF (+) |
| 2026-01-18 00:24:10 +0100 | <EvanR> | makeF add x = add (x - 1) (x + 1) |
| 2026-01-18 00:22:58 +0100 | <EvanR> | tying |
| 2026-01-18 00:22:54 +0100 | <EvanR> | as far as knot typing I don't know about this |
| 2026-01-18 00:22:50 +0100 | <monochrom> | Oh, like "f x = f (x - 1) + f (x - 1)" vs "f x = let y = f (x - 1) in y + y"? |
| 2026-01-18 00:22:27 +0100 | <EvanR> | dependency isn't dynamically changing* |
| 2026-01-18 00:21:38 +0100 | <EvanR> | this assumes the dependent implementation isn't dynamically changing for the same data structure |
| 2026-01-18 00:21:14 +0100 | <EvanR> | instead of every time it's accessed |
| 2026-01-18 00:21:01 +0100 | <EvanR> | if you're combining implementations in a way to implement another implementation, you do want to use prudent "let" bindings to make sure you only access the dependent implementation once |
| 2026-01-18 00:18:34 +0100 | <EvanR> | holy moly |
| 2026-01-18 00:18:24 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2026-01-18 00:18:13 +0100 | <haskellbridge> | <Man of Letters (Mikolaj)> but the nested array indexing code implements what should be in that dictionary --- I'd need a way to somehow boostrap this, recurse across a dictionary |
| 2026-01-18 00:17:26 +0100 | <haskellbridge> | <Man of Letters (Mikolaj)> if I understand your idea correctly, the nested array indexing code should instead take a dictionary that directly works on nested arrays, not vectors |
| 2026-01-18 00:16:51 +0100 | <haskellbridge> | <Man of Letters (Mikolaj)> so, the only argument against I can find is circularity: say, I'm implementing indexing in fancy nested arrays (which is called 12! times in the benchmark I'm working on), the code for the indexing takes a dictionary for storable vectors (the arrays are represented as tuples of such vectors) and it's terribly slow when it has to access the dictionary each time it's called |
| 2026-01-18 00:15:01 +0100 | ethantwardy | (~user@user/ethantwardy) (Client Quit) |
| 2026-01-18 00:14:14 +0100 | ethantwardy | (~user@user/ethantwardy) ethantwardy |
| 2026-01-18 00:13:13 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-01-18 00:11:40 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2026-01-18 00:09:58 +0100 | ethantwardy | (~user@user/ethantwardy) (Client Quit) |
| 2026-01-18 00:07:35 +0100 | ethantwardy | (~user@user/ethantwardy) ethantwardy |
| 2026-01-18 00:06:38 +0100 | <haskellbridge> | <Man of Letters (Mikolaj)> that makes sense; let me think why not |
| 2026-01-18 00:05:34 +0100 | <EvanR> | any time you pass around explicit dictionaries, can't it also be passing (perhaps hidden inside a data type) a record of things doing the implementation |
| 2026-01-18 00:05:18 +0100 | <haskellbridge> | <Man of Letters (Mikolaj)> because what I'm currently doing is seriously embarrassing |
| 2026-01-18 00:02:52 +0100 | <haskellbridge> | <Man of Letters (Mikolaj)> but if anybody has any other ideas how to avoid passing around explicit dictionaries but maintain the very abstract API, I'm all ears |
| 2026-01-18 00:02:38 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2026-01-18 00:02:06 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Quit: Leaving...) |
| 2026-01-18 00:01:44 +0100 | <haskellbridge> | <Man of Letters (Mikolaj)> * specializing/monomorphizing |
| 2026-01-18 00:01:30 +0100 | <haskellbridge> | <Man of Letters (Mikolaj)> this is a code base with a huge amount of existential types, which totally block any sane ways of specializing code |
| 2026-01-18 00:00:53 +0100 | <haskellbridge> | <Man of Letters (Mikolaj)> the idea is (and it works and speeds up runtime considerably) that I add lots of INLINEs and INLINEABLE and then in each line starting with "Is @<some type>" a function is either inlined or called (but with unfolding available), which GHC now sees operating at concrete type, so it specializes the function (or its inlining) to that specific type |
| 2026-01-17 23:58:48 +0100 | <haskellbridge> | <Man of Letters (Mikolaj)> but the hacks in my code are actually poor man's monomorphisation, so they need to be so crude |
| 2026-01-17 23:58:13 +0100 | <haskellbridge> | <Man of Letters (Mikolaj)> Leary: yay, that's impressive; I may use this for something in the future, but |
| 2026-01-17 23:57:24 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-01-17 23:54:24 +0100 | <Leary> | Man of Letters (Mikolaj): That's a big improvement, but there's still a lot of duplication. Consider something like this: https://gist.github.com/LSLeary/4db7ad8d3068ee493d3d075df02b01e7 |
| 2026-01-17 23:47:47 +0100 | Inline | (~User@2001-4dd6-dd24-0-d5a6-802e-e6e6-ce59.ipv6dyn.netcologne.de) Inline |
| 2026-01-17 23:46:56 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2026-01-17 23:46:36 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-01-17 23:45:44 +0100 | Zemy_ | (~Zemy@2600:100c:b04a:cc3c:d838:d5ff:fe1f:3ebe) (Ping timeout: 260 seconds) |
| 2026-01-17 23:43:33 +0100 | Inline | (~User@2001-4dd6-dd24-0-886a-5b51-ee9-3d0b.ipv6dyn.netcologne.de) (Ping timeout: 256 seconds) |
| 2026-01-17 23:41:40 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-01-17 23:41:34 +0100 | Zemy | (~Zemy@72.178.108.235) |
| 2026-01-17 23:40:05 +0100 | Zemy | (~Zemy@72.178.108.235) (Ping timeout: 244 seconds) |
| 2026-01-17 23:36:45 +0100 | Zemy_ | (~Zemy@2600:100c:b04a:cc3c:d838:d5ff:fe1f:3ebe) |
| 2026-01-17 23:30:35 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |