2025/04/01

Newest at the top

2025-04-01 17:32:21 +0200tromp(~textual@2001:1c00:3487:1b00:29bc:7fae:9d9f:d545) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-04-01 17:32:11 +0200 <tomsmeding> what are you reading?
2025-04-01 17:31:56 +0200 <EvanR> the one I was reading said strict bindings are not allowed at top level but I guess that's old now?
2025-04-01 17:31:42 +0200 <int-e> as you said (failed to delete)
2025-04-01 17:31:34 +0200 <tomsmeding> I'm half-sure this changed at some point
2025-04-01 17:31:34 +0200 <int-e> but (!x) is still top-level,
2025-04-01 17:31:26 +0200 <tomsmeding> but "top-level" may be under parentheses
2025-04-01 17:31:16 +0200 <EvanR> that would be an interesting thing to optimize out
2025-04-01 17:31:12 +0200 <tomsmeding> ah no, there is a semantical difference between a top-level bang pattern in a let binding, and a bang somewhere nested
2025-04-01 17:31:02 +0200 <lambdabot> *Exception: <<loop>>
2025-04-01 17:31:00 +0200 <int-e> > let a = let (!(x,y)) = a in (0,x) in a
2025-04-01 17:30:38 +0200 <lambdabot> (0,0)
2025-04-01 17:30:36 +0200 <int-e> > let a = let (x,y) = a in (0,x) in a
2025-04-01 17:30:32 +0200 <lambdabot> *Exception: <<loop>>
2025-04-01 17:30:30 +0200 <tomsmeding> or wait
2025-04-01 17:30:29 +0200 <int-e> > let a = let !(x,y) = a in (0,x) in a
2025-04-01 17:30:17 +0200 <EvanR> o_O
2025-04-01 17:30:08 +0200 <tomsmeding> ah, the GHC docs for BangPatterns point out that `let !x` is not the same as `let (!x)`
2025-04-01 17:28:51 +0200 <tomsmeding> precisely
2025-04-01 17:28:47 +0200 <EvanR> i.e. using lub
2025-04-01 17:28:40 +0200 <EvanR> crashing or freezing due to bottom might be an intended observable effect
2025-04-01 17:28:08 +0200 <merijn> I need to rereads the documentation on bangpatterns
2025-04-01 17:28:03 +0200 <tomsmeding> otherwise what would the bang pattern even mean
2025-04-01 17:27:53 +0200 <tomsmeding> yes
2025-04-01 17:27:47 +0200 <merijn> tomsmeding: I meant that if the entire binding is unused does GHC keep it just for forcing the evaluation?
2025-04-01 17:27:46 +0200 <EvanR> unfortunately, the rule I just posted doesn't apply to this specific let, you need one of the other semantic rules... and there's a lot apparently for bang patterns
2025-04-01 17:27:12 +0200 <tomsmeding> it's not optimiser vagaries
2025-04-01 17:27:05 +0200 <tomsmeding> merijn: uh, bang patterns have semantics :p
2025-04-01 17:26:55 +0200 <merijn> I'm not sure
2025-04-01 17:26:52 +0200 <merijn> As in, if you don't use either x or y is there a chance it gets optimised away
2025-04-01 17:26:42 +0200 <lambdabot> "ok"
2025-04-01 17:26:40 +0200 <EvanR> > let (x,y) = undefined in "ok"
2025-04-01 17:26:35 +0200 <lambdabot> "*Exception: Prelude.undefined
2025-04-01 17:26:33 +0200 <EvanR> > let !(x,y) = undefined in "ok"
2025-04-01 17:26:09 +0200 <EvanR> ????
2025-04-01 17:25:53 +0200 <merijn> I'm not sure you can ever observe the difference between those two, EvanR
2025-04-01 17:25:09 +0200werneta(~werneta@syn-071-083-160-242.res.spectrum.com) (Ping timeout: 248 seconds)
2025-04-01 17:24:37 +0200 <tomsmeding> indeed, `case _ of !(x,y) -> _` is equivalent to `case _ of (x,y) -> _`
2025-04-01 17:24:15 +0200 <tomsmeding> in `let (x,y) = e in body`, e might not get evaluated at all if x and y are unused
2025-04-01 17:23:45 +0200 <EvanR> but in case alternatives it has no effect
2025-04-01 17:23:25 +0200 <EvanR> so let !(x,y) = e in body is substantially different from let (x,y) = e in body, because e gets evaluated earlier. Right?
2025-04-01 17:19:12 +0200tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh
2025-04-01 17:17:42 +0200acidjnk_new(~acidjnk@p200300d6e71c4f82640579a6e00084b6.dip0.t-ipconnect.de) acidjnk
2025-04-01 17:06:11 +0200kawzeg(kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) kawzeg
2025-04-01 17:04:41 +0200 <EvanR> some kinda monad or smth
2025-04-01 17:04:36 +0200acidjnk_new(~acidjnk@p200300d6e71c4f8289e7d3d4c6144767.dip0.t-ipconnect.de) (Ping timeout: 246 seconds)
2025-04-01 17:01:25 +0200 <hellwolf> frontend is voodoo to me... sounds like you can use some monad
2025-04-01 17:01:04 +0200ubert(~Thunderbi@2a02:8109:ab8a:5a00:74f1:1caf:2629:a3c8) ubert
2025-04-01 16:58:22 +0200 <tomsmeding> I don't know why ace.js thought it was a good idea to explicitly clear undo history when setting the contents of an edit session to a new srting
2025-04-01 16:57:46 +0200 <hellwolf> tomsmeding: great!