Newest at the top
| 2025-12-26 19:53:37 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-26 19:43:01 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-12-26 19:42:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-12-26 19:42:50 +0100 | rainbyte | (~rainbyte@186.22.19.214) (Read error: Connection reset by peer) |
| 2025-12-26 19:42:48 +0100 | rainbyte_ | (~rainbyte@186.22.19.214) rainbyte |
| 2025-12-26 19:38:10 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-26 19:27:37 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-12-26 19:22:23 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-26 19:15:19 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) (Remote host closed the connection) |
| 2025-12-26 19:15:02 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) emmanuelux |
| 2025-12-26 19:11:23 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-26 19:06:34 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-26 18:59:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 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 |