[bitc-dev] Rationale for unboxed mutability in BitC?

[David Hopwood]

Swaroop Sridhar wrote:
> [2] Design of Type and Mutability Inference in BitC
> http://www.coyotos.org/docs/bitc/mutinfer.html

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>