Newest at the top
| 2025-12-26 18:55:10 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-26 18:48:04 +0100 | tabemann | (~tabemann@12.215.215.61) (Quit: Leaving) |
| 2025-12-26 18:46:53 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2025-12-26 18:43:55 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 240 seconds) |
| 2025-12-26 18:39:29 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2025-12-26 18:37:53 +0100 | <haskellbridge> | <Liamzee> https://hackage-content.haskell.org/package/ghc-internal-9.1401.0/docs/src/GHC.Internal.IO.Unsafe.… |
| 2025-12-26 18:37:51 +0100 | <haskellbridge> | <Liamzee> Also: |
| 2025-12-26 18:37:38 +0100 | <ncf> | yeah that's the point |
| 2025-12-26 18:37:19 +0100 | <ncf> | it also comes up here https://proofassistants.stackexchange.com/a/932 as the "irrelevance axiom" |
| 2025-12-26 18:37:19 +0100 | <ski> | "How does it matter that it's still using the original RealWorld?" -- mm, i guess it means the action can't be scheduled to happen before the invocation of `unsafeInterleaveIO' happens |
| 2025-12-26 18:36:40 +0100 | <ncf> | if you replace IO with propositional truncation, then the assumption of choice as above is equivalent to the "world's smallest axiom of choice" (choice over propositions) |
| 2025-12-26 18:36:10 +0100 | <ncf> | it comes up in https://lmcs.episciences.org/3217/pdf theorem 7.7 |
| 2025-12-26 18:35:36 +0100 | <ski> | mm |
| 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 |