Newest at the top
| 2025-12-26 18:35:04 +0100 | <ncf> | yeah, it has the form of the premise. i don't think it's really related though, since we're not interested in taking fixed points |
| 2025-12-26 18:34:37 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-12-26 18:34:36 +0100 | <ski> | type reminds me a little of `loeb :: Functor f => f (f a -> a) -> f a' |
| 2025-12-26 18:34:31 +0100 | <ncf> | in terms of the state monad, choice s = (\ k -> fst (k s), s) |
| 2025-12-26 18:34:06 +0100 | <haskellbridge> | ... long message truncated: https://kf8nh.com/_heisenbridge/media/kf8nh.com/pUZqcmzrNFjqpSRguxhgPvfI/iqhSMNoSnW4 (3 lines) |
| 2025-12-26 18:34:03 +0100 | <haskellbridge> | <Liamzee> now that i think about it: is it true that unsafeInterleaveIO ma = pure (unsafePerformIO ma) ? it sure seems like that's what the implementation is doing |
| 2025-12-26 18:33:20 +0100 | <ski> | (aka `($ ma) <$> choice') |
| 2025-12-26 18:32:59 +0100 | <ncf> | yeah |
| 2025-12-26 18:32:47 +0100 | <ski> | you mean `choice <*> pure ma' ? |
| 2025-12-26 18:32:07 +0100 | <ncf> | (i call it choice because it's a form of choice if you replace IO with a propositional truncation modality, but this is a bad name) |
| 2025-12-26 18:31:41 +0100 | <ncf> | given choice, you can implement unsafeInterleaveIO ma = choice <*> ma |
| 2025-12-26 18:31:21 +0100 | <ncf> | well, not equivalent, more primitive |
| 2025-12-26 18:30:42 +0100 | <ncf> | so an equivalent formulation of unsafeInterleaveIO should be choice :: IO (IO a → a) |
| 2025-12-26 18:28:28 +0100 | <haskellbridge> | <Liamzee> via a copy |
| 2025-12-26 18:28:21 +0100 | <haskellbridge> | <Liamzee> but w/e this is fancy, I'll be happy just to get RecordBatch from arrow-rs being converted to a dataframe without segfaulting |
| 2025-12-26 18:27:54 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-12-26 18:27:47 +0100 | ttybitnik | (~ttybitnik@user/wolper) ttybitnik |
| 2025-12-26 18:27:45 +0100 | <haskellbridge> | <Liamzee> TBH I'm still looking at FFI and I'm thinking about using unsafeInterleaveIO with a mutex to allow streaming of FFI read-in-place |
| 2025-12-26 18:27:44 +0100 | <ski> | you'd not be surprised by an I/O action in an invocation of `forkIO' happening at different times, on different runs, so you should also not be surprised by the I/O with `unsafeInterleaveIO' being hard to predict when it happens |
| 2025-12-26 18:27:09 +0100 | <ncf> | ah, not quite, it's using the input RealWorld instead of creating one out of thin air |
| 2025-12-26 18:26:32 +0100 | <ncf> | now that i think about it: is it true that unsafeInterleaveIO ma = pure (unsafePerformIO ma) ? it sure seems like that's what the implementation is doing |
| 2025-12-26 18:25:20 +0100 | <ski> | otoh, this argument does not work for `unsafeInterleaveST', there's no concurrency in `ST s' |
| 2025-12-26 18:24:01 +0100 | <ski> | iow, the "have a pure function trigger an effect on its own simply by evaluating a value that causes unsafeInterleaveIO to throw effects" would be a particular implementation choice, for efficiency, but the compiler would be allowed to schedule the I/O to happen earlier (and so earlier than other I/O actions not sequenced wrt this one), if it could show that the result value would eventually get forced |
| 2025-12-26 18:21:21 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-26 18:21:18 +0100 | <ski> | happened before forcing the returned value, if that happens) |
| 2025-12-26 18:21:12 +0100 | <ski> | Liamzee : there is an argument that observed differences in behaviour as to if and when the I/O occurs, is due to the nondeterminacy of the `IO' in the result type of `unsafeInterleaveIO', similarly to how `forkIO' (concurrency) introduce nondeterminacy with how threads will be scheduled wrt each other. iow, `unsafeInterleaveIO' would guarantee that the I/O might or might not happen (but obviously must've |
| 2025-12-26 18:20:42 +0100 | <c_wraith> | Compare that to unsafeInterleaveST, which leaves no traces behind.... |
| 2025-12-26 18:20:03 +0100 | <c_wraith> | At least there's still an IO in the type at the end to tell you there are effects going on. |
| 2025-12-26 18:17:52 +0100 | synchromesh | (~john@2406:5a00:2412:2c00:68ff:586d:59bf:bb1) synchromesh |
| 2025-12-26 18:16:43 +0100 | <ncf> | oh never mind, i misread |
| 2025-12-26 18:16:33 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2025-12-26 18:16:25 +0100 | synchromesh | (~john@2406:5a00:2412:2c00:68ff:586d:59bf:bb1) (Read error: Connection reset by peer) |
| 2025-12-26 18:15:31 +0100 | <ncf> | ? |
| 2025-12-26 18:14:14 +0100 | <haskellbridge> | <Liamzee> I thought of it more like, actions doing so |
| 2025-12-26 18:14:04 +0100 | <haskellbridge> | <Liamzee> i just never thought about it in the sense of having pure functions evaluate through unsafeInterleaveIO |
| 2025-12-26 18:13:23 +0100 | <geekosaur> | and why it's `unsafe` |
| 2025-12-26 18:13:17 +0100 | sroso | (~sroso@user/SrOso) SrOso |
| 2025-12-26 18:13:11 +0100 | <geekosaur> | yep, that's exactly the point of it |
| 2025-12-26 18:12:54 +0100 | <haskellbridge> | <Liamzee> but, implicitly, i can have a pure function trigger an effect on its own simply by evaluating a value that causes unsafeInterleaveIO to throw effects |
| 2025-12-26 18:12:42 +0100 | <geekosaur> | yes |
| 2025-12-26 18:11:43 +0100 | <haskellbridge> | <Liamzee> umm, been thinking, doesn't unsafeInterleaveIO violate referential transparency? I guess that's implied by the name! |
| 2025-12-26 18:10:20 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-12-26 18:05:34 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-26 17:56:39 +0100 | Digitteknohippie | Digit |
| 2025-12-26 17:56:37 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-26 17:51:40 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-26 17:40:49 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-12-26 17:37:59 +0100 | ZLima12 | (~zlima12@user/meow/ZLima12) (Ping timeout: 260 seconds) |
| 2025-12-26 17:37:44 +0100 | ZLima12_ | (~zlima12@user/meow/ZLima12) ZLima12 |
| 2025-12-26 17:36:09 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |