Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It sounds like you're using "inlining" to mean "stack-allocating the closure", but when I think of "inlining" I think of "expanding a function body into its call sites to elide function-call overhead". Maybe there's an implicit relationship between the two that I'm not understanding? I guess in order to stack allocate a closure you have to generate new function instances for each "type" of closure, and since these types rarely change between call sites we just inline them? Apologies if I'm just dense.


> "stack-allocating the closure"

Regular function (not heap allocated closures) do not have a runtime footprint. Their body just gets tracked by the partial evaluator, but never manifests unless they are applied. Their variables (usually stack-alloc'd) get tracked on an individual basis.

So it is not the case that functions are stack allocated. They are fully known.

A closure is something that is opaque to the partial evaluator. Closures do need to be heap allocated because they could be recursive data types.

> "expanding a function body into its call sites to elide function-call overhead"

If you do this, not only do you not need the function call overhead, but you also do not need the overhead from heap allocating a function a runtime (converting it into a closure.)

I am not sure how good I am at explaining this. I would appreciate somebody going over the docs and giving me some feedback on it. When the last Spiral was posted on HN, there was some initial excitement for a few days and then it was crickets.

If you are willing to give it a try, I'd be happy to answer all your questions in the Spiral issues.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: