Newest at the top
2025-09-15 01:08:22 +0200 | mange | (~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 +0200 | cyphase | (~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 +0200 | cyphase_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 +0200 | tilde | zzz |
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 |