Newest at the top
| 2025-12-22 21:45:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-22 21:44:28 +0100 | polykernel_ | (~polykerne@user/polykernel) polykernel |
| 2025-12-22 21:40:38 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-22 21:38:13 +0100 | itaipu | (~itaipu@168.121.97.28) itaipu |
| 2025-12-22 21:36:58 +0100 | itaipu | (~itaipu@168.121.97.28) (Ping timeout: 255 seconds) |
| 2025-12-22 21:29:41 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2025-12-22 21:24:50 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-22 21:21:29 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-12-22 21:16:11 +0100 | spew | (~spew@user/spew) (Quit: nyaa~) |
| 2025-12-22 21:15:40 +0100 | pavonia | (~user@user/siracusa) siracusa |
| 2025-12-22 21:13:37 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-22 21:06:47 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-22 21:01:19 +0100 | mastarija | (~mastarija@9-118.dsl.iskon.hr) (Quit: Client closed) |
| 2025-12-22 21:01:15 +0100 | synchromesh | (~john@2406:5a00:2412:2c00:1031:6e9d:4234:64a3) synchromesh |
| 2025-12-22 20:59:48 +0100 | synchromesh | (~john@2406:5a00:2412:2c00:1031:6e9d:4234:64a3) (Read error: Connection reset by peer) |
| 2025-12-22 20:59:48 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-12-22 20:55:43 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-22 20:51:57 +0100 | <mastarija> | Optimizations related to some "laws", not in general. |
| 2025-12-22 20:51:02 +0100 | <mastarija> | But it does recognize some things IIRC and can apply some optimizations in certain cases. |
| 2025-12-22 20:50:59 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-22 20:50:55 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 252 seconds) |
| 2025-12-22 20:50:48 +0100 | <geekosaur> | ghc knows nothing about laws. some RULES assume that various laws hold, meaning they produce breakage if they don't, but nothing checks or otherwise uses them |
| 2025-12-22 20:50:10 +0100 | <mastarija> | No :) |
| 2025-12-22 20:49:26 +0100 | <EvanR> | to simplify things |
| 2025-12-22 20:49:13 +0100 | <EvanR> | does GHC use "laws" of typeclasses in general? |
| 2025-12-22 20:45:21 +0100 | Googulator89 | (~Googulato@2a01-036d-0106-48e4-3c18-a4bd-1bda-7c8b.pool6.digikabel.hu) |
| 2025-12-22 20:45:05 +0100 | Googulator89 | (~Googulato@2a01-036d-0106-48e4-3c18-a4bd-1bda-7c8b.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-22 20:43:46 +0100 | <mastarija> | Arrows have some benefits like being statically analyzable and in theory we can perform more optimizations on them. Can Arrows reap some of those static analysis benefits in the current GHC or are we just limited to things like preventing memory leaks in parsers and FRP? |
| 2025-12-22 20:42:25 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-12-22 20:41:27 +0100 | vidak | (~vidak@2407:e400:7800:2c01:d0be:76f8:cc84:bd4a) vidak |
| 2025-12-22 20:41:02 +0100 | mastarija | (~mastarija@9-118.dsl.iskon.hr) mastarija |
| 2025-12-22 20:39:21 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-12-22 20:37:22 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-22 20:37:18 +0100 | <monochrom> | data ChItem a = ChItem a (MVar (ChItem a)) |
| 2025-12-22 20:36:14 +0100 | <monochrom> | Err s/MChan/Chan/ |
| 2025-12-22 20:35:10 +0100 | <EvanR> | where A = B because we're trying to swap |
| 2025-12-22 20:34:38 +0100 | <monochrom> | I think MChan is like that. |
| 2025-12-22 20:34:33 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2025-12-22 20:34:17 +0100 | <EvanR> | xD |
| 2025-12-22 20:34:16 +0100 | <EvanR> | MVar (A, MVar B) |
| 2025-12-22 20:34:02 +0100 | <EvanR> | ensure that like this |
| 2025-12-22 20:33:55 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 240 seconds) |
| 2025-12-22 20:33:14 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-12-22 20:28:21 +0100 | <monochrom> | Actually you can just perform two takeMVars then two putMVars. You already have atomicity. If every site does it in the same order, you won't have deadlocks. |
| 2025-12-22 20:27:32 +0100 | shaeto | (~Shaeto@94.25.234.244) (Quit: WeeChat 4.1.1) |
| 2025-12-22 20:26:15 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 240 seconds) |
| 2025-12-22 20:26:10 +0100 | Googulator | (~Googulato@2a01-036d-0106-48e4-3c18-a4bd-1bda-7c8b.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-22 20:25:59 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2025-12-22 20:25:48 +0100 | Googulator89 | (~Googulato@2a01-036d-0106-48e4-3c18-a4bd-1bda-7c8b.pool6.digikabel.hu) |
| 2025-12-22 20:24:53 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 252 seconds) |