Home liberachat/#haskell: Logs Calendar

Logs: liberachat/#haskell

←Prev  Next→ 1,804,052 events total
2025-09-14 22:34:15 jreicher joins (~user@user/jreicher)
2025-09-14 22:34:31 <haskellbridge> <magic_rb> right, in that syntax no
2025-09-14 22:34:34 <haskellbridge> <magic_rb> in my syntax yes
2025-09-14 22:35:03 <haskellbridge> <magic_rb> and it works when i only apply UPDATE when the H[y] is a PAP, FUN, or value (think i32, f32, String)
2025-09-14 22:35:52 <haskellbridge> <magic_rb> i need to figure out how closely do i need to follow the paper, because my thing is interpreting an untyped language and is also not a compiler, but a interpreter/VM
2025-09-14 22:36:01 <haskellbridge> <magic_rb> so i think im stretching this a bit
2025-09-14 22:36:32 <int-e> well, the function call rules rely on those restrictions; there's no rule that applies to (g 5) 4; ... because (g 5) is not a variable. You can modify those but then you're on your own and things that work fine with the original rules may go wrong.
2025-09-14 22:37:08 <haskellbridge> <magic_rb> i dont have (g 5) 4
2025-09-14 22:37:20 <haskellbridge> <magic_rb> i have (THUNK (g 5)) 4 and that works
2025-09-14 22:37:39 <haskellbridge> <magic_rb> whether the THUNK is inline or bound through a let is implementation details, it shouldnt affect semantics
2025-09-14 22:38:08 <haskellbridge> <magic_rb> but i do agree that my STG type being able to represent an invalid tree is problematic
2025-09-14 22:38:43 <jreicher> What do you mean by an "invalid tree"? (Sorry, coming into this a bit late)
2025-09-14 22:39:15 <int-e> Right, you have (FUN (y -> FUN (x -> x))) 5, but basically the same comment applies: (FUN ...) is not a variable.
2025-09-14 22:39:29 <int-e> (as the expression in that thunk)
2025-09-14 22:40:48 <int-e> And to overcome this within the rules of the paper, you have to let-bind that function.
2025-09-14 22:41:05 <int-e> hence let g = FUN (y -> FUN (x -> x)) in g
2025-09-14 22:44:05 <int-e> and actually that's still wrong, because FUN ... is a heap object, and only the rhs of let-s are heap objects. So it'll actually be let g = FUN (y -> let h = FUN (x -> x) in h) in g.
2025-09-14 22:46:51 tilde is now known as zzz
2025-09-14 22:47:23 <int-e> the final `in g` is supposed to be `in g 5` both times
2025-09-14 22:48:13 <haskellbridge> <magic_rb> yes because within the rules of that paper, let bindings create thunks?
2025-09-14 22:48:25 <haskellbridge> <magic_rb> in the current constraints of my think, i can insert thunks anywhere
2025-09-14 22:48:32 <haskellbridge> <magic_rb> so that alleviates that problem
2025-09-14 22:48:33 <int-e> let bindings create new heap objects
2025-09-14 22:48:39 <haskellbridge> <magic_rb> yep
2025-09-14 22:48:39 <haskellbridge> <magic_rb> okay
2025-09-14 22:48:43 <jreicher> And they're not necessarily thunks
2025-09-14 22:49:17 <int-e> right
2025-09-14 22:49:22 <haskellbridge> <magic_rb> when can they be not thunks?
2025-09-14 22:49:31 <jreicher> When they're functions
2025-09-14 22:49:44 <int-e> or fully saturated constructors
2025-09-14 22:49:58 <haskellbridge> <magic_rb> i dont have constructors in my thing, and probably wont, nix doesnt have them
2025-09-14 22:49:59 <haskellbridge> <magic_rb> but uh
2025-09-14 22:50:05 <haskellbridge> <magic_rb> as for the function thing
2025-09-14 22:50:14 <haskellbridge> <magic_rb> oh right
2025-09-14 22:50:14 <haskellbridge> <magic_rb> yes
2025-09-14 22:50:33 <haskellbridge> <magic_rb> okay, so we have let f = \x -> x in f 4
2025-09-14 22:51:13 <haskellbridge> <magic_rb> but f = THUNK ( let g = (\y \x -> x) in g 5 ) in f 4
2025-09-14 22:51:29 <haskellbridge> <magic_rb> right? the inner one doesnt have to be thunk
2025-09-14 22:51:36 <haskellbridge> <magic_rb> because its a FUN
2025-09-14 22:52:00 <haskellbridge> <magic_rb> the outer one is neither a let, as such it needs a thunk
2025-09-14 22:52:15 <int-e> you /can/ have let f = THUNK (let g = FUN (y x -> x) in g 5) in f 4
2025-09-14 22:52:34 <haskellbridge> <magic_rb> isnt that exactly what i typed
2025-09-14 22:52:55 <haskellbridge> <magic_rb> jreicher im implementing my own version of the STG, or at least trying to, then building a Nix frontend on top
2025-09-14 22:53:06 <int-e> let f = THUNK (let g = FUN (y -> let h = FUN (x -> x) in h) in g 5) in f 4 was me being faithful to the distinction betwenn \y -> \x -> x and \y x -> x that is occasionally relevant
2025-09-14 22:53:19 <int-e> I know that it's different from what you wrote; I corrected it
2025-09-14 22:53:25 <haskellbridge> <magic_rb> ah sorry
2025-09-14 22:53:37 × cyphase_eviltwin quits (~cyphase@user/cyphase) (Ping timeout: 248 seconds)
2025-09-14 22:53:40 <int-e> (\y \x -> x) isn't a heap object
2025-09-14 22:53:46 <haskellbridge> <magic_rb> im a bit too sleepy for this, but i think you unblocked me, because the thing seems to work, so thanks
2025-09-14 22:55:20 <haskellbridge> <magic_rb> ill go to bed now, my let bindings are wrong still i think, they dont get updated properly (they dont have thunks, so obviously they dont)
2025-09-14 22:56:44 <jreicher> int-e: OK, but I'm not sure what's "invalid" here? (I'm probably missing something)
2025-09-14 23:00:10 <int-e> jreicher: this is in reference to https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/eval-apply.pdf , which describes an STG-like language. And the expression syntax there has let x = obj in e, where `obj` must be a heap object, which starts with FUN, PAP, CON, THUNK, or BLACKHOLE... (\y \x -> x) is none of these.
2025-09-14 23:00:58 cyphase joins (~cyphase@user/cyphase)
2025-09-14 23:03:31 <jreicher> int-e: yep know the paper well. Ironically I last read it too long ago to have everything fresh in my memory.
2025-09-14 23:03:56 <haskellbridge> <magic_rb> Right i actually have that in my huge match statement lol, the body of an application must be a heap object, which is exactly what i was struggling with, makes sense
2025-09-14 23:04:18 <haskellbridge> <magic_rb> But yeah, im writing an interpreter so im taking a lot of liberties
2025-09-14 23:05:07 <haskellbridge> <magic_rb> I will bring this closer to what the paper is describing just for consistency, though ill use a lisp like syntax, im not writing a parser for the stg syntax presented in the paper
2025-09-14 23:05:44 <haskellbridge> <magic_rb> Then ill expand the nix frontend and then see what needs optimizing. Since i was told that microbenchmarking nix is impossible ....
2025-09-14 23:08:22 mange joins (~mange@user/mange)
2025-09-14 23:21:08 pavonia joins (~user@user/siracusa)
2025-09-14 23:27:24 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-09-14 23:38:42 × mreh quits (~matthew@host86-146-25-35.range86-146.btcentralplus.com) (Ping timeout: 260 seconds)
2025-09-14 23:38:44 merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
2025-09-14 23:43:55 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds)
2025-09-14 23:47:34 × Tuplanolla quits (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.)
2025-09-14 23:53:37 × Alleria quits (~Alleria@user/alleria) (Read error: Connection reset by peer)
2025-09-14 23:53:53 segfaultfizzbuzz joins (~segfaultf@12.172.219.17)
2025-09-14 23:57:07 Alleria joins (~Alleria@user/alleria)
2025-09-14 23:57:15 × acidjnk quits (~acidjnk@p200300d6e7171917d8d62854256e96a7.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2025-09-15 00:08:52 merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
2025-09-15 00:10:54 × ljdarj quits (~Thunderbi@user/ljdarj) (Quit: ljdarj)
2025-09-15 00:13:44 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-09-15 00:17:00 × otto_s quits (~user@p4ff27811.dip0.t-ipconnect.de) (Ping timeout: 245 seconds)
2025-09-15 00:18:44 otto_s joins (~user@p4ff27b4b.dip0.t-ipconnect.de)
2025-09-15 00:24:39 merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
2025-09-15 00:29:24 × infinity0 quits (~infinity0@pwned.gg) (Remote host closed the connection)
2025-09-15 00:29:47 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-09-15 00:32:18 × califax quits (~califax@user/califx) (Remote host closed the connection)
2025-09-15 00:33:24 califax joins (~califax@user/califx)
2025-09-15 00:34:05 infinity0 joins (~infinity0@pwned.gg)
2025-09-15 00:38:41 × infinity0 quits (~infinity0@pwned.gg) (Ping timeout: 250 seconds)
2025-09-15 00:40:27 × trickard quits (~trickard@cpe-56-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-09-15 00:40:27 merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
2025-09-15 00:40:40 trickard_ joins (~trickard@cpe-56-98-47-163.wireline.com.au)
2025-09-15 00:43:17 trickard_ is now known as trickard
2025-09-15 00:47:21 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds)
2025-09-15 00:49:24 × califax quits (~califax@user/califx) (Remote host closed the connection)
2025-09-15 00:49:40 califax joins (~califax@user/califx)
2025-09-15 00:49:48 merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
2025-09-15 00:50:10 × segfaultfizzbuzz quits (~segfaultf@12.172.219.17) (Ping timeout: 265 seconds)
2025-09-15 00:55:00 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2025-09-15 00:56:54 humasect joins (~humasect@dyn-192-249-132-90.nexicom.net)
2025-09-15 00:58:46 infinity0 joins (~infinity0@pwned.gg)
2025-09-15 01:05:30 merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl)
2025-09-15 01:09:30 × humasect quits (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection)
2025-09-15 01:10:09 × trickard quits (~trickard@cpe-56-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-09-15 01:10:22 trickard_ joins (~trickard@cpe-56-98-47-163.wireline.com.au)
2025-09-15 01:10:41 × merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-09-15 01:12:12 andrew joins (~andrew@138-51-70-206-lsn-2.nat.utoronto.ca)
2025-09-15 01:15:14 × tremon quits (~tremon@83.80.159.219) (Quit: getting boxed in)

All times are in UTC.