[bitc-dev] constraining bitc's type system

Sam Mason sam at samason.me.uk
Fri Sep 15 17:26:06 CDT 2006


On Fri, Sep 15, 2006 at 03:54:50PM -0400, Jonathan S. Shapiro wrote:
> If you try to think of it as
> template expansion you'll end up with the right understanding.

That's how I've been thinking about it so far.

> I do not expect that we will be able to restrict polyinstantiation for
> value types. Carrying dictionary pointers introduces a hidden
> performance cost, and for systems programs that should not happen
> without the programmer knowing about it explicitly.

That's one of the main things I was trying to avoid.

> > Section 5.4 (Interaction with ``Relaxed'' Value Restriction) of the
> > paper Swaroop is writing has the following example:
> > 
> >   (define p:(mutable bool, 'a) (#t, none))
> >   val p: (mutable bool, (optional 'b))
> > 
> >   (let ((r1:(optional int8)   p.snd)
> >         (r2:(optional double) p.snd)) ... )
> > 
> > which is a problem because optional is a value type and hence it's size
> > is determined by its parameter type.
> 
> Actually, in this case the size isn't a problem, because you only copy
> the fields that are in the active leg.

I was just picking on it because it was a case where the polyinstantiator
would kick in adding potential unknowns to the runtime characteristics
of the code.

> > The only way I can see out of this is to require polymorphic members
> > to be boxed.  I have a feeling that this is what Garrigue's restriction
> > effectively does in BitC, but haven't entirely convinced myself of it yet.
> > It guess it would be possible to allow functions to pass boxed types
> > around with polymorphic members as long as they are treated as opaquely.
> 
> No no. This is precisely what must NOT happen. What needs to happen is
> for the polyinstantiator to kick in.

I think I just want to know *when* the polyinstantiator is going to
kick in.  Maybe it is something that will just become natural.  I know
with higher level languages like ML and Haskell I quickly forgot about the
memory issues that had plagued my design decisions in C (and to a lesser
extent Java).  But sometimes (systems code being the classic example)
it is necessary to know that the computer is doing exactly what your
code told it to do.


  Sam


More information about the bitc-dev mailing list