[bitc-dev] Linear BitC?

[Greg Buchholz]

    I was browsing through the BitC spec, and I noticed that section 9,
"Storage Model" was missing.  Since BitC is for operating systems, I
figured garbage collection would probably be a tough problem.  Scanning
the mailing list archives shows that region allocation has already been
dismissed.  So I thought I'd ask what people thought of using
linearity/uniqueness in a language in order to eliminate garbage
collection.  I'm specifically thinking of Henry Baker's collection of
papers [1] discussing linearity.  Examples...

'Use-Once' Variables and Linear Objects -- Storage Management,
 Reflection and Multi-Threading
http://home.pipeline.com/~hbaker1/Use1Var.html

   "The intuition behind linear types is the conservation of physical
    matter--a linear object cannot be created or destroyed without special
    permission, although it can be moved or transferred at will. Thus, an
    occurrence of a linear variable--e.g., in the argument list of a
    function call--indicates that the function will consume the value of the
    variable. If the function does not later return this value, either as a
    returned value, or by assigning it to a more global variable, then that
    function is responsible for properly disposing of any of the resources
    controlled by the value--even in the case of exceptions." 

Lively Linear Lisp -- 'Look Ma, No Garbage!'
http://home.pipeline.com/~hbaker1/LinearLisp.html

    We show an efficient implementation of linear logic called Linear Lisp
    that runs within a constant factor of non-linear logic. This Linear Lisp
    allows RPLACX operations, and manages storage as safely as a non-linear
    Lisp, but does not need a garbage collector. Since it offers assignments
    but no sharing, it occupies a twilight zone between functional languages
    and imperative languages. Our Linear Lisp Machine offers many of the
    same capabilities as combinator/graph reduction machines, but without
    their copying and garbage collection problems.

...I couldn't help but think that some of these ideas might be
applicable to BitC/Coyotos/Hurd.  Thoughts?


Thanks,

Greg Buchholz

[1] http://home.pipeline.com/~hbaker1/home.html