Newest at the top
| 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 |
| 2024-11-18 20:55:13 +0100 | troydm | (~troydm@user/troydm) troydm |
| 2024-11-18 20:55:07 +0100 | <davean> | I mean you can pass laziness through IO |
| 2024-11-18 20:54:44 +0100 | <geekosaur> | right, but at that point I think I say "just do it in IO, you will be sad otherwise" |
| 2024-11-18 20:54:43 +0100 | <SrPx> | the problem is that, now, the 'normal' function (which calls whnf-reduce layer by layer) is extremely eager. if I normalize a term and drop it, it will still fully normalize the term because the whole thing has to be wrapped in IO |
| 2024-11-18 20:54:19 +0100 | <davean> | geekosaur: right, but see what he said "I do need the ability to do IO inside "pure" functions (because I'm using C FFI for performance)" |
| 2024-11-18 20:54:00 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2024-11-18 20:53:59 +0100 | <geekosaur> | ah |
| 2024-11-18 20:53:44 +0100 | <SrPx> | davean: to be more specific, this is for an evaluator. the runtime is in C, including the "whnf-reduce" function. that function does, internally, effectiful things such as allocating memory and writing to the global heap. as such, whnf-reduce must be wrapped in IO - it isn't a pure function |
| 2024-11-18 20:53:43 +0100 | <geekosaur> | you can do pure FFI, if you know the C function you are calling has no side effects and in particular doesn't allocate |
| 2024-11-18 20:53:29 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2024-11-18 20:52:50 +0100 | <davean> | I'm lost as to the connection you're making |
| 2024-11-18 20:52:38 +0100 | kaskal | (~kaskal@213-147-165-220.nat.highway.webapn.at) kaskal |