Newest at the top
| 2024-11-18 21:34:42 +0100 | zmt01 | (~zmt00@user/zmt00) zmt00 |
| 2024-11-18 21:33:54 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) Smiles |
| 2024-11-18 21:33:43 +0100 | briandaed | (~root@user/briandaed) (Remote host closed the connection) |
| 2024-11-18 21:32:17 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Quit: ash3en) |
| 2024-11-18 21:31:24 +0100 | michalz | (~michalz@185.246.207.197) (Remote host closed the connection) |
| 2024-11-18 21:28:53 +0100 | <haskellbridge> | <hellwolf> cool |
| 2024-11-18 21:22:46 +0100 | kaskal | (~kaskal@84-115-237-124.cable.dynamic.surfer.at) kaskal |
| 2024-11-18 21:22:04 +0100 | <haskellbridge> | <sm> 😎 |
| 2024-11-18 21:22:00 +0100 | kaskal- | (~kaskal@84-115-237-124.cable.dynamic.surfer.at) (Quit: ZNC - https://znc.in) |
| 2024-11-18 21:19:54 +0100 | sprotte24 | (~sprotte24@p200300d16f36e9004570e4f99d260ace.dip0.t-ipconnect.de) |
| 2024-11-18 21:17:20 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-18 21:15:11 +0100 | kaskal | (~kaskal@213-147-165-220.nat.highway.webapn.at) (Ping timeout: 265 seconds) |
| 2024-11-18 21:13:41 +0100 | kaskal- | (~kaskal@84-115-237-124.cable.dynamic.surfer.at) |
| 2024-11-18 21:12:46 +0100 | <SrPx> | like mindblowingly cool |
| 2024-11-18 21:12:17 +0100 | <SrPx> | ty |
| 2024-11-18 21:12:15 +0100 | <SrPx> | and that's extremely cool |
| 2024-11-18 21:12:11 +0100 | <SrPx> | it works flawlessly guys. the interaction count decreases based on the terms I actually observe in Haskell. so basically Haskell-side laziness propagates to HVM in the sense if you discard an HVM term Haskell-side, you won't pay for it |
| 2024-11-18 21:10:30 +0100 | kupi | (uid212005@id-212005.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-11-18 21:09:54 +0100 | Square | (~Square@user/square) Square |
| 2024-11-18 21:04:46 +0100 | <davean> | Yah this sounds more ST than IO |
| 2024-11-18 21:03:05 +0100 | <mauke> | so I figure if it is morally "like ST", then it should be OK |
| 2024-11-18 21:02:52 +0100 | <mauke> | runST exists |
| 2024-11-18 21:02:41 +0100 | <davean> | C FFI doesn't mean you have to have IO |
| 2024-11-18 21:02:38 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-18 21:02:25 +0100 | <SrPx> | so, as long as I guarantee reduce acts purely, it is ok to import it as a pure function, even thought it isn't |
| 2024-11-18 21:02:06 +0100 | <mauke> | (of course, that won't work if it takes/returns pointers) |
| 2024-11-18 21:01:56 +0100 | <SrPx> | mauke: makes sense |
| 2024-11-18 21:01:29 +0100 | <mauke> | if so, you can just import it at a pure type |
| 2024-11-18 21:01:18 +0100 | <SrPx> | davean: that might be a better idea actually... |
| 2024-11-18 21:01:08 +0100 | <SrPx> | davean: you mean in the sense I could wrap unsafePerformIO into the reduce() function I get from C? |
| 2024-11-18 21:00:53 +0100 | <mauke> | is reduce a C function? |
| 2024-11-18 21:00:42 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-11-18 21:00:41 +0100 | <SrPx> | and it works! |
| 2024-11-18 21:00:40 +0100 | <davean> | SrPx: Then it might be pure and not involve IO at all? |
| 2024-11-18 21:00:02 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-11-18 20:59:59 +0100 | <SrPx> | ah, based on this I'm good to use it. reduce() will always return the same result, even though it mutates memory internally. ty guys |
| 2024-11-18 20:59:34 +0100 | <SrPx> | "In general, it is up to you to prove that your use of unsafeInterleaveIO is safe. If you call unsafeInterleaveIO x, then you have to prove that x can be called at any time and still produce the same output." |
| 2024-11-18 20:59:30 +0100 | <davean> | SrPx: It will run the whole IO, but IO can pass and produce lazy values just fine |
| 2024-11-18 20:59:29 +0100 | <mauke> | gives you stdin as a lazy string |
| 2024-11-18 20:57:50 +0100 | <SrPx> | mauke: no, what is that? |
| 2024-11-18 20:57:47 +0100 | <SrPx> | interestingly, seems like there is a SO thread about exactly that: https://stackoverflow.com/questions/13263692/when-is-unsafeinterleaveio-unsafe |
| 2024-11-18 20:57:27 +0100 | <mauke> | are you familiar with getContents? |
| 2024-11-18 20:57:05 +0100 | <SrPx> | mauke: I've just learned about it, seems like what I need. although documentation isn't clear on how it could break things |
| 2024-11-18 20:56:48 +0100 | <SrPx> | no. it is true that you can pass IO around lazily. yet, within the context of the execution of IO monad, calls will not be evaluated lazily - Haskell will run the whole IO, even if some parts aren't visible (see my example) |
| 2024-11-18 20:56:31 +0100 | <mauke> | unsafeInterleaveIO exists |
| 2024-11-18 20:56:15 +0100 | Angelz | (Angelz@Angelz.oddprotocol.org) (Ping timeout: 246 seconds) |
| 2024-11-18 20:55:45 +0100 | <davean> | I mean that is what IO already does. |
| 2024-11-18 20:55:33 +0100 | <SrPx> | what will happen exactly? |
| 2024-11-18 20:55:30 +0100 | <SrPx> | so I can't interleave IO calls to happen only when Haskell's lazy evaluator reaches an expression? ): |
| 2024-11-18 20:55:17 +0100 | <davean> | IO doesn't remove laziness |