Newest at the top
| 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) |
| 2025-12-22 20:24:44 +0100 | <monochrom> | Yeah STM should be much simpler. But sometimes there are causes for sticking to MVars. You never know the context of contextless generic questions! |
| 2025-12-22 20:24:33 +0100 | <gentauro> | EvanR: linear-types? |
| 2025-12-22 20:23:51 +0100 | <EvanR> | atomic swap of two MVars sounds like someone screaming out for STM |
| 2025-12-22 20:21:40 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2025-12-22 20:13:35 +0100 | <iqubic> | Those would be useful for me, and I'm not really seeing what prevents those from existing. |
| 2025-12-22 20:13:33 +0100 | <monochrom> | Zemyla: Add one more MVar to atomize the swapping of two existing MVars! |