The regions+mutability discussion prompts me to a thought about unboxing.
In the previous thread, I proposed a mental model in which all fields,
locals, parameters, and return types are of the form "ref !Access 'Type in
%Region". In passing, I went and introduced a distinguished region
%Literal. It is conventional in region systems to include a distinguished
region %Heap (though that's not always the name) that is the containing
region for all memory.
So now let's consider a "sane syntax" declaration:
struct S { i : int; f: float; }; // intent is that i, f will be unboxed
in the proposed mental model, this types as follows:
struct !mutability S %r_S {
i : ref immutable int %r_i;
f : ref immutable float %r_f;
};
So here's my question: if we intend that i and f should be unboxed within
S, isn't it sufficient to unify %r_S, %r_i, and %r_f?
I understand that this doesn't address the question of *placement* within
S. What I'm wondering is whether "unboxed" is best understood as a
shorthand that means "unify my region with that of my container". In the
case of a struct field, the container is the struct. In the case of a
let-bound variable, the container is the frame (or more accurately, the
scope, which is in turn contained by the frame). Conversely, "boxed" simply
means that there is no presumptive relation between the two regions (though
constraints might add such relations).
I'm not sure whether this is practically valuable from a compilation
standpoint, but it would sure be nice to simplify the core semantics if
this seems plausible.
Is this a sound interpretation of the meaning of unboxed and boxed?
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
