Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Unboxed Closures #153
Currently, when a function is placed on the stack, its closure variables are copied to a new heap-allocated structure. I believe it’s possible to avoid this in the following way:
For (4), I’m not yet sure whether the types will work out when converting the CPS continuation to a closure itself—need to make sure this terminates.
I don’t believe we need to surface existentials to the user—they can be an intermediate step only. Existentials would be useful in their own right, but would require additional design work. Tentative syntax would be
It’s also worth noting that
I’ve been thinking more about incorporating first-class unboxed existentials, and I have a sketch of a design. As a bonus, it would give us a more elegant implementation of closures.
Note that this wouldn’t compile if the existential contained
I don’t want to have to add a subtyping relationship between function pointers and functions with closures, so the surface syntax should probably always produce closures; if they don’t capture anything, we can allow existentials that quantify over no types
We may also need to store size information in kinds, in order to deal with higher-rank polymorphism over unboxed types.
For packing, rather than