Newest at the top
| 2024-12-22 06:23:54 +0100 | <monochrom> | Having said that, if you say you are only using GHC, then you know it almost sticks to "use lazy for non-strict, use eager for strict". But there are occasional deviations when the code optimizer thinks it's more efficient to do it some other way. |
| 2024-12-22 06:21:38 +0100 | <haskellbridge> | <Bowuigi> I see, yeah Haskell can be hard to understand sometimes lol |
| 2024-12-22 06:17:53 +0100 | poscat0x04 | (~poscat@user/poscat) poscat |
| 2024-12-22 06:17:42 +0100 | poscat | (~poscat@user/poscat) (Read error: Connection reset by peer) |
| 2024-12-22 06:17:32 +0100 | <monochrom> | Denotational semantics strives to (even prides in) avoid talking about them. |
| 2024-12-22 06:16:58 +0100 | <monochrom> | Yes absolutely. If you want to predict how much time and how much space are spent, they emphatically require knowing the evaluation strategy, i.e., operational. |
| 2024-12-22 06:15:40 +0100 | <haskellbridge> | <Bowuigi> So the duplication is operational right? |
| 2024-12-22 06:14:59 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-12-22 06:13:46 +0100 | <monochrom> | So even the "eager : lazy :: strict : non-strict" "correspondence" is easily broken. |
| 2024-12-22 06:13:16 +0100 | <monochrom> | there is also speculative evaluation, it can result in non-strict while being even more eager than eager. |
| 2024-12-22 06:13:16 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2024-12-22 06:12:44 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2024-12-22 06:12:34 +0100 | <haskellbridge> | <Bowuigi> Oh there we go |
| 2024-12-22 06:12:19 +0100 | <haskellbridge> | <Bowuigi> That's why I prefer working with total languages lol |
| 2024-12-22 06:12:09 +0100 | <monochrom> | eager and lazy |
| 2024-12-22 06:12:02 +0100 | <monochrom> | denotational means you only talk about whether you get an answer and what answer if yes, it deliberately avoids how the computer manages to do it. |
| 2024-12-22 06:11:46 +0100 | <haskellbridge> | <Bowuigi> So what do you call the operational notion? |
| 2024-12-22 06:10:45 +0100 | <monochrom> | Ugh no, strictness is a denotational notion, not an operational (evaluation) notion. A strict function means f bottom = bottom. |
| 2024-12-22 06:10:45 +0100 | Guest78 | (~Guest78@213.233.155.134) |
| 2024-12-22 06:10:10 +0100 | Guest78 | (~Guest78@37.228.252.73) (Ping timeout: 240 seconds) |
| 2024-12-22 06:09:37 +0100 | <haskellbridge> | <Bowuigi> Strict evaluation would evaluate the value once and possibly duplicate other computations inside that value |
| 2024-12-22 06:08:37 +0100 | <haskellbridge> | <Bowuigi> Space leaks are caused by duplication of code, code is duplicated wherever variables are duplicated in lazy evaluation |
| 2024-12-22 06:07:52 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-22 06:07:30 +0100 | <orangeflu> | and why is the laziness causing me space leaks while strictness wouldn't? |
| 2024-12-22 06:06:35 +0100 | <haskellbridge> | <Bowuigi> "Eager" is "fully evaluate", "Strict" is "evaluate only what I'm directly responsible for" and "Lazy" is "evaluate only what I will pattern match on, as I pattern match on it". Or at least that seems to be the general consensus |
| 2024-12-22 06:05:55 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-12-22 06:05:41 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2024-12-22 06:05:35 +0100 | califax | (~califax@user/califx) califx |
| 2024-12-22 06:05:18 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2024-12-22 06:05:18 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-12-22 06:05:18 +0100 | <orangeflu> | c_wraith: what do you think about the project? |
| 2024-12-22 06:04:16 +0100 | <haskellbridge> | <Bowuigi> Yes, but not eagerly either |
| 2024-12-22 06:03:41 +0100 | <orangeflu> | when you say 'strict', do you mean not lazily? |
| 2024-12-22 06:03:41 +0100 | housemate | (~housemate@124.187.109.206) housemate |
| 2024-12-22 06:02:43 +0100 | <haskellbridge> | <Bowuigi> Passing state around in a strict way, along with nice syntax sugar is what this is supposed to do |
| 2024-12-22 06:01:02 +0100 | <orangeflu> | anyway) |
| 2024-12-22 06:00:55 +0100 | <orangeflu> | i know what a state monad is, i think. like, if i have a function, that takes a container and returns a modified container and a result, i can chain them together with do notation. that's what i understand anyway. But how is that different from what i'm doing now? except for the fact that i don't chain them in a do block (which wouldn't be useful anyway, cause i don't execute instructions that way |
| 2024-12-22 05:58:10 +0100 | housemate | (~housemate@124.187.109.206) (Quit: Nothing to see here. I wasn't there. I take IRC seriously.) |
| 2024-12-22 05:58:10 +0100 | <haskellbridge> | <Bowuigi> Hmmm moving to a strict state monad to handle your emulator state could also help. It attacks space leaks more directly and is a smaller change |
| 2024-12-22 05:57:03 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-12-22 05:56:33 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2024-12-22 05:56:06 +0100 | <haskellbridge> | <Bowuigi> MVector is a somewhat extreme solution, mutable stuff is fairly common in heavily optimized programs/libraries like smalltt or flatparse (there are a lot more examples but I know those two more in depth than anything else) |
| 2024-12-22 05:56:01 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2024-12-22 05:55:39 +0100 | xff0x | (~xff0x@p3704193-ipxg12201sapodori.hokkaido.ocn.ne.jp) (Ping timeout: 265 seconds) |
| 2024-12-22 05:55:02 +0100 | <orangeflu> | thing is, this is both a learning project and something that i want to be useful |
| 2024-12-22 05:54:35 +0100 | <orangeflu> | i'm sure i did a horrible job of writing this and there are a bunch of stuff that make no sense or could be optimized heavily |
| 2024-12-22 05:53:42 +0100 | <haskellbridge> | <Bowuigi> There might be a more obvious refactor that we missed tho |
| 2024-12-22 05:52:47 +0100 | <haskellbridge> | <Bowuigi> Just like optimization in other languages ofc |
| 2024-12-22 05:52:31 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-12-22 05:52:25 +0100 | <haskellbridge> | <Bowuigi> With MVector you need something like IO everywhere yes. Haskell optimization is not for begginners |