Newest at the top
| 2025-02-21 11:21:29 +0100 | gabriel_sevecek | (~gabriel@188-167-229-200.dynamic.chello.sk) gabriel_sevecek |
| 2025-02-21 11:21:00 +0100 | gabriel_sevecek | (~gabriel@188-167-229-200.dynamic.chello.sk) (Ping timeout: 276 seconds) |
| 2025-02-21 11:19:19 +0100 | misterfish | (~misterfis@h239071.upc-h.chello.nl) (Ping timeout: 260 seconds) |
| 2025-02-21 11:14:51 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-02-21 11:13:30 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 272 seconds) |
| 2025-02-21 11:08:57 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-21 11:08:51 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2025-02-21 11:06:10 +0100 | Googulator85 | (~Googulato@81.183.235.203) (Ping timeout: 240 seconds) |
| 2025-02-21 10:56:52 +0100 | Googulator85 | (~Googulato@81.183.235.203) |
| 2025-02-21 10:56:51 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-02-21 10:56:31 +0100 | Googulator85 | (~Googulato@81.183.235.203) (Quit: Client closed) |
| 2025-02-21 10:53:55 +0100 | comerijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Read error: Connection reset by peer) |
| 2025-02-21 10:53:44 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-02-21 10:51:38 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 244 seconds) |
| 2025-02-21 10:39:52 +0100 | hattckory | (~hattckory@149.102.242.103) |
| 2025-02-21 10:39:40 +0100 | hattckory | (~hattckory@149.102.242.103) (Remote host closed the connection) |
| 2025-02-21 10:35:10 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-02-21 10:34:32 +0100 | Googulator85 | (~Googulato@81.183.235.203) |
| 2025-02-21 10:33:14 +0100 | acidjnk | (~acidjnk@p200300d6e7283f0719c6a4240347dc57.dip0.t-ipconnect.de) acidjnk |
| 2025-02-21 10:32:26 +0100 | comerijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-21 10:27:54 +0100 | random-jellyfish | (~developer@user/random-jellyfish) random-jellyfish |
| 2025-02-21 10:27:00 +0100 | <ski> | (in Concurrent ML (library model for concurrency, available for some ML systems), you can construct "events", which will trigger upon certain conditions. you can syncrhonize/await on such an event. given an event, you can attach a post-processing step to it, to be applied to the generated value, when the event triggers. this basically forms a monad (so covariant functor), iirc) |
| 2025-02-21 10:24:53 +0100 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) |
| 2025-02-21 10:24:18 +0100 | <ski> | thirdofmay18081814goya : read-only view of a mutable cell can be made covariant, write-only view can be made contravariant -- if we allow attaching a post- / pre- processing step to them, respectively. ditto for read-end and write-end of a concurrent channel |
| 2025-02-21 10:23:54 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-02-21 10:21:53 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
| 2025-02-21 10:21:35 +0100 | <haskellbridge> | <magic_rb> Anyone seen the person behind https://github.com/l-Shane-l/tiny-wlhs around? I seem to recall seeing them either here or in the matrix room. Im thinking about just hard switching to it, to force myself to fix any bugs i run into :) |
| 2025-02-21 10:19:28 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-21 10:18:04 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 260 seconds) |
| 2025-02-21 10:17:25 +0100 | Guest5922 | vpan |
| 2025-02-21 10:17:06 +0100 | sprotte24 | (~sprotte24@p200300d16f15cb0045bb3ddcfddbb48e.dip0.t-ipconnect.de) |
| 2025-02-21 10:16:59 +0100 | vpan | Guest5922 |
| 2025-02-21 10:16:35 +0100 | vpan | (~vpan@212.117.1.172) |
| 2025-02-21 10:13:34 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
| 2025-02-21 10:07:59 +0100 | vpan | (~vpan@212.117.1.172) (Ping timeout: 260 seconds) |
| 2025-02-21 10:04:52 +0100 | <dminuoso> | I'm not sure. |
| 2025-02-21 10:04:45 +0100 | <dminuoso> | And Star generalizes to arbitrary Functor? |
| 2025-02-21 10:04:38 +0100 | <dminuoso> | My feeling is that Kleisli uses `liftM` in a bunch of places, perhaps because there may be edge cases where it may be faster than a generalized `fmap`? |
| 2025-02-21 10:03:40 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 252 seconds) |
| 2025-02-21 10:02:50 +0100 | <dminuoso> | Im not entirely sure why both `Star` and `Kleisli` exist. |
| 2025-02-21 10:02:47 +0100 | vpan | (~vpan@212.117.1.172) |
| 2025-02-21 10:01:51 +0100 | <dminuoso> | Ah let me make one correction, of course for Kleisli technically we only need `Functor`. |
| 2025-02-21 09:57:11 +0100 | <haskellbridge> | <thirdofmay18081814goya> this point of view was extremely helpful, ty! the definition makes perfect sense now |
| 2025-02-21 09:56:00 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 264 seconds) |
| 2025-02-21 09:55:45 +0100 | <dminuoso> | Just like you can map over inputs (contravariantly) and outputs (covariantly) in `a -> b` |
| 2025-02-21 09:55:28 +0100 | <dminuoso> | Because at the end, even in `a -> IO b` you can map over the input, and the eventual output of the IO action. |
| 2025-02-21 09:54:54 +0100 | <dminuoso> | So this starts to generalize even more. |
| 2025-02-21 09:54:36 +0100 | <dminuoso> | But it's really just about `a -> IO b`. And it so happens that for every Monad m, `Kleisli m` is such a profunctor. |
| 2025-02-21 09:53:56 +0100 | <dminuoso> | Except because of how our typesystem works we have to make it a `newtype Kleisli m a b = Kleisli { runKleisli a -> m b }` and call `Kleisli IO` a profunctor. |
| 2025-02-21 09:53:21 +0100 | <dminuoso> | Say `a -> IO b` is something that you too can see as an (effectul) transformation |