[bitc-dev] A curious question

Sam Mason sam at samason.me.uk
Wed Jan 23 14:22:39 EST 2008

On Wed, Jan 23, 2008 at 11:58:53AM -0500, Swaroop Sridhar wrote:
> Jonathan S. Shapiro wrote:
> > As we contemplate an s-block syntax for BitC, one question that emerges
> > is initialization rules. In particular, BitC really wants to require
> > that pointer slots (a) be initialized, and (b) be non-null.
> > 
> > In the lispish surface syntax this doesn't feel awkward, but in an
> > s-block surface syntax we will soon want to introduce something like a
> > constructor, and we will then get into situations where we say "field p
> > must be a non-null pointer to a mumble", but field p will not be
> > initialized at the first line of the constructor.
> > 
> > From a safety perspective, I believe that the following constraints are
> > sufficient to ensure safety:
> > 
> >   1. Field p must be properly initialized to a non-null pointer
> >      before it is used.

Do null pointers ever get exposed to the user?  I believe Optional/Maybe
types are to be implmented as null values, but that's not quite the same
in my mind.

> >   2. The object pointer must not escape from the constructor
> >      until all such type safety constraints are satisified.
> >      In particular this constrains exception values.
> > First, does everyone agree that these conditions are sufficient?
> > 
> > Second, do we believe that we can specify an algorithm for checking this
> > property so that it can be statically determined at source level whether
> > a program is well-formed w.r.t. type safety?
> Is the condition is same as saying `p' must never be used as an
> rvalue before being initialized? This condition is certainly sufficient.

How well does this interact with garbage collection?  It seems as
though you're going to have things on the stack that are known to be
uninitalised pointers.  Can these be flagged to the garbage collector,
or is the current frame special somehow?

I've just reread the message and noticed that your comments were really
aimed at structures, does that mean you're only worried about the heap
at the moment?


More information about the bitc-dev mailing list