2025/09/14

Newest at the top

2025-09-15 01:08:22 +0200mange(~mange@user/mange) mange
2025-09-15 01:05:44 +0200 <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-15 01:05:07 +0200 <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-15 01:04:18 +0200 <haskellbridge> <magic_rb> But yeah, im writing an interpreter so im taking a lot of liberties
2025-09-15 01:03:56 +0200 <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-15 01:03:31 +0200 <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-15 01:00:58 +0200cyphase(~cyphase@user/cyphase) cyphase
2025-09-15 01:00:10 +0200 <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-15 00:56:44 +0200 <jreicher> int-e: OK, but I'm not sure what's "invalid" here? (I'm probably missing something)
2025-09-15 00:55:20 +0200 <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-15 00:53:46 +0200 <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-15 00:53:40 +0200 <int-e> (\y \x -> x) isn't a heap object
2025-09-15 00:53:37 +0200cyphase_eviltwin(~cyphase@user/cyphase) (Ping timeout: 248 seconds)
2025-09-15 00:53:25 +0200 <haskellbridge> <magic_rb> ah sorry
2025-09-15 00:53:19 +0200 <int-e> I know that it's different from what you wrote; I corrected it
2025-09-15 00:53:06 +0200 <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-15 00:52:55 +0200 <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-15 00:52:34 +0200 <haskellbridge> <magic_rb> isnt that exactly what i typed
2025-09-15 00:52:15 +0200 <int-e> you /can/ have let f = THUNK (let g = FUN (y x -> x) in g 5) in f 4
2025-09-15 00:52:00 +0200 <haskellbridge> <magic_rb> the outer one is neither a let, as such it needs a thunk
2025-09-15 00:51:36 +0200 <haskellbridge> <magic_rb> because its a FUN
2025-09-15 00:51:29 +0200 <haskellbridge> <magic_rb> right? the inner one doesnt have to be thunk
2025-09-15 00:51:13 +0200 <haskellbridge> <magic_rb> but f = THUNK ( let g = (\y \x -> x) in g 5 ) in f 4
2025-09-15 00:50:33 +0200 <haskellbridge> <magic_rb> okay, so we have let f = \x -> x in f 4
2025-09-15 00:50:14 +0200 <haskellbridge> <magic_rb> yes
2025-09-15 00:50:14 +0200 <haskellbridge> <magic_rb> oh right
2025-09-15 00:50:05 +0200 <haskellbridge> <magic_rb> as for the function thing
2025-09-15 00:49:59 +0200 <haskellbridge> <magic_rb> but uh
2025-09-15 00:49:58 +0200 <haskellbridge> <magic_rb> i dont have constructors in my thing, and probably wont, nix doesnt have them
2025-09-15 00:49:44 +0200 <int-e> or fully saturated constructors
2025-09-15 00:49:31 +0200 <jreicher> When they're functions
2025-09-15 00:49:22 +0200 <haskellbridge> <magic_rb> when can they be not thunks?
2025-09-15 00:49:17 +0200 <int-e> right
2025-09-15 00:48:43 +0200 <jreicher> And they're not necessarily thunks
2025-09-15 00:48:39 +0200 <haskellbridge> <magic_rb> okay
2025-09-15 00:48:39 +0200 <haskellbridge> <magic_rb> yep
2025-09-15 00:48:33 +0200 <int-e> let bindings create new heap objects
2025-09-15 00:48:32 +0200 <haskellbridge> <magic_rb> so that alleviates that problem
2025-09-15 00:48:25 +0200 <haskellbridge> <magic_rb> in the current constraints of my think, i can insert thunks anywhere
2025-09-15 00:48:13 +0200 <haskellbridge> <magic_rb> yes because within the rules of that paper, let bindings create thunks?
2025-09-15 00:47:23 +0200 <int-e> the final `in g` is supposed to be `in g 5` both times
2025-09-15 00:46:51 +0200tildezzz
2025-09-15 00:44:05 +0200 <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-15 00:41:05 +0200 <int-e> hence let g = FUN (y -> FUN (x -> x)) in g
2025-09-15 00:40:48 +0200 <int-e> And to overcome this within the rules of the paper, you have to let-bind that function.
2025-09-15 00:39:29 +0200 <int-e> (as the expression in that thunk)
2025-09-15 00:39:15 +0200 <int-e> Right, you have (FUN (y -> FUN (x -> x))) 5, but basically the same comment applies: (FUN ...) is not a variable.
2025-09-15 00:38:43 +0200 <jreicher> What do you mean by an "invalid tree"? (Sorry, coming into this a bit late)
2025-09-15 00:38:08 +0200 <haskellbridge> <magic_rb> but i do agree that my STG type being able to represent an invalid tree is problematic
2025-09-15 00:37:39 +0200 <haskellbridge> <magic_rb> whether the THUNK is inline or bound through a let is implementation details, it shouldnt affect semantics