Newest at the top
2024-10-06 22:25:07 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) justsomeguy |
2024-10-06 22:24:29 +0200 | zetef | (~quassel@5.14.128.142) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
2024-10-06 22:17:42 +0200 | <Inst> | whoops, ghci error, running tests, this doesn't happen, score |
2024-10-06 22:16:13 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
2024-10-06 22:11:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
2024-10-06 22:10:51 +0200 | gmg | (~user@user/gehmehgeh) gehmehgeh |
2024-10-06 22:07:47 +0200 | euphores | (~SASL_euph@user/euphores) euphores |
2024-10-06 22:07:25 +0200 | <Inst> | i can compose linear functions in haskell with just ordinary . |
2024-10-06 22:07:06 +0200 | <Inst> | hmmm, that's interesting |
2024-10-06 22:06:40 +0200 | target_i | (~target_i@user/target-i/x-6023099) target_i |
2024-10-06 22:03:01 +0200 | [exa] | (~exa@user/exa/x-3587197) [exa] |
2024-10-06 22:02:28 +0200 | zetef | (~quassel@5.14.128.142) zetef |
2024-10-06 22:01:30 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
2024-10-06 22:01:15 +0200 | euphores | (~SASL_euph@user/euphores) (Ping timeout: 246 seconds) |
2024-10-06 22:00:15 +0200 | nckx | nckhexen |
2024-10-06 21:58:54 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
2024-10-06 21:57:43 +0200 | [exa] | (~exa@user/exa/x-3587197) (Quit: WeeChat 3.0) |
2024-10-06 21:56:14 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
2024-10-06 21:53:36 +0200 | gmg | (~user@user/gehmehgeh) (Ping timeout: 260 seconds) |
2024-10-06 21:52:33 +0200 | ethantwardy | (user@user/ethantwardy) ethantwardy |
2024-10-06 21:51:06 +0200 | <Inst> | or .%% |
2024-10-06 21:48:48 +0200 | <Inst> | the only plus side is that no one is using %%. |
2024-10-06 21:48:29 +0200 | <Inst> | define programmer :) |
2024-10-06 21:48:11 +0200 | <Inst> | I'm trying to figure out whether you can use linear functions via import without having -XLinearHaskell |
2024-10-06 21:48:11 +0200 | <stefan-__> | (I am using "-fprof-auto") |
2024-10-06 21:47:46 +0200 | <monochrom> | This is why programmers can always benefit from a "theoretical" CS education. |
2024-10-06 21:47:40 +0200 | <stefan-__> | any idea why GHC's profiling system creates weird cost centers? e.g. according to https://42dots.de/ghcprofview-01.png 53% of the individual time is spent in lines 374-391 in the module https://gist.github.com/dozed/affa3fc39410c20d13a3e466ce2795d0#file-xeno8a-hs-L374-L391 which is a let expression |
2024-10-06 21:46:07 +0200 | <monochrom> | And Python does a hybrid thing (list of arrays) to try to be the best of both worlds but you can also force it into worst of both worlds. |
2024-10-06 21:45:39 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
2024-10-06 21:45:34 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2024-10-06 21:44:49 +0200 | <monochrom> | Even with mutable arrays, that is, in C and Java etc., cons is still not great. Only amortized O(1), not worst-case O(1). |
2024-10-06 21:43:54 +0200 | ethantwardy | (user@user/ethantwardy) (Ping timeout: 260 seconds) |
2024-10-06 21:43:48 +0200 | <Inst> | *Kovacs |
2024-10-06 21:43:42 +0200 | <Inst> | Vector has to be O(n) cons because of immutable data, that's why AndrasKovac's library (last maintained in 2017) focuses on mutable vectors |
2024-10-06 21:43:11 +0200 | <Inst> | that said, there's still a lacuna |
2024-10-06 21:42:51 +0200 | <Inst> | once again, I'm an imbecile |
2024-10-06 21:42:26 +0200 | pie_ | (~pie_bnc@user/pie/x-2818909) __ |
2024-10-06 21:42:12 +0200 | pie_ | (~pie_bnc@user/pie/x-2818909) () |
2024-10-06 21:40:48 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) merijn |
2024-10-06 21:40:41 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
2024-10-06 21:40:24 +0200 | <haskellbridge> | <aaron> I think the solver still ends up requiring manual help when using the constraint then, which is the problem we're trying to solve. Could be wrong though, I should try it again |
2024-10-06 21:38:22 +0200 | <Lears> | Pointless restrictions are very annoying, but you can still work around it with `class Ob (Dom f) a => ObDom f a; class Ob (Cod f) a => ObCod f a`. |
2024-10-06 21:36:06 +0200 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
2024-10-06 21:35:01 +0200 | <haskellbridge> | <aaron> but that's not what was implemented |
2024-10-06 21:34:41 +0200 | <haskellbridge> | <aaron> I don't see why it shouldn't work. Type families should be allowed in the head as long as they don't reference the quantified variables (or more generally, as long as the head is injective in the quantified variables) |
2024-10-06 21:31:28 +0200 | <tomsmeding> | oof that looks like a tricky QC for sure |
2024-10-06 21:31:24 +0200 | AlexNoo_ | AlexNoo |
2024-10-06 21:31:07 +0200 | <tomsmeding> | I recall Edsko (I think) writing somewhere that he wasn't quite sure why that workaround was not built into GHC |
2024-10-06 21:30:59 +0200 | <haskellbridge> | <aaron> Lears: think the issue was when a type family is an argument, e.g. "forall a. Ob (Dom f) a => Ob (Cod f) (f a)" where "Dom" and "Cod" are type families |
2024-10-06 21:30:08 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |