2024/12/22

Newest at the top

2024-12-22 06:47:00 +0100CrunchyFlakes(~CrunchyFl@31.19.233.78)
2024-12-22 06:46:21 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds)
2024-12-22 06:46:10 +0100alecs(~alecs@61.pool85-58-154.dynamic.orange.es) alecs
2024-12-22 06:44:30 +0100CrunchyFlakes(~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2024-12-22 06:41:18 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2024-12-22 06:39:28 +0100tnt1(~Thunderbi@user/tnt1) tnt1
2024-12-22 06:33:05 +0100tnt1(~Thunderbi@user/tnt1) (Ping timeout: 248 seconds)
2024-12-22 06:30:30 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2024-12-22 06:25:54 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2024-12-22 06:25:14 +0100ryanbooker(uid4340@id-4340.hampstead.irccloud.com) (Quit: Connection closed for inactivity)
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 +0100poscat0x04(~poscat@user/poscat) poscat
2024-12-22 06:17:42 +0100poscat(~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 +0100merijn(~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 +0100chexum(~quassel@gateway/tor-sasl/chexum) chexum
2024-12-22 06:12:44 +0100chexum(~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 +0100Guest78(~Guest78@213.233.155.134)
2024-12-22 06:10:10 +0100Guest78(~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 +0100merijn(~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 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2024-12-22 06:05:41 +0100ChaiTRex(~ChaiTRex@user/chaitrex) ChaiTRex
2024-12-22 06:05:35 +0100califax(~califax@user/califx) califx
2024-12-22 06:05:18 +0100ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2024-12-22 06:05:18 +0100califax(~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 +0100housemate(~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 +0100housemate(~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 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)