[bitc-dev] Rationale for unboxed mutability in BitC?
david.nospam.hopwood at blueyonder.co.uk
Fri Sep 15 09:38:19 CDT 2006
Swaroop Sridhar wrote:
>  Design of Type and Mutability Inference in BitC
Why do you argue that 'high-performance "systems" codes' require *unboxed*
mutability, in particular?
My impression is that this choice seems to be imposing a great deal of
complexity on BitC's type system, and a requirement to invent type system
features that only have marginal relevance to BitC's main goals.
I hope that boxing in a language's semantics is not being confused with
boxing in a language's implementation. In the latter, it is of course
possible to "inline" ref cells into the representation of a structure or
array, and this seems to give the performance advantages of unboxed
mutability, while still allowing to use a well-understood ML-style type
system. Or is there some other argument for unboxed mutability in the
semantics that I'm missing?
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>
More information about the bitc-dev