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

[Jonathan S. Shapiro]

On Fri, 2006-09-15 at 16:53 +0100, Sam Mason wrote:
> On Fri, Sep 15, 2006 at 03:38:19PM +0100, David Hopwood wrote:
> > Or is there some other argument for unboxed mutability in the
> > semantics that I'm missing?
> 
> I see two main arguments leading to it:
> 
>  1. If BitC is going to be used in the kernel then you need to be able to
>     make guarantees about how things are organised in memory (i.e. the
>     page tables in an Intel processor need to structured correctly).
>     Making these guarantees when you have an unpredictable (to anyone
>     except the author of the optimiser) middle man is difficult.

Yes. When a programmer declares that something is to be unboxed, this is
not a request. It is an imperative directive. The decision to unbox is
part of the language semantics, and must be so.

Mutable unboxed objects derives from the need to efficiently manipulate
low-level data structures. While there *is* one example of an OS
attempting to do this using the Haskell I/O monad (house/hop),
performance has not been a consideration in that work.

Finally, there is a need to interface with existing C-based data
structures.

>  2. Fancy optimisers make for lots of non-trivial code and lots code
>     means even more proof (which is going to be difficult enough even
>     for a small compiler).

And how!