[bitc-dev] BitC Records Figure fixed

[Jonathan S. Shapiro]

On Thu, 2004-12-23 at 19:42 -0500, Swaroop Sridhar wrote:
> > The definition of the type of a record in our language should be based 
> > on Field Types AND Field ordering AND Field names AND record-name.

I'm not sure who is being quoted here, and it would be very helpful to
know. I begin to suspect that we have a more fundamental issue here that
I have failed to understand.

First, I believe that structures *must* define field order and field
type in order to be useful for the kinds of applications we are
building. This does not correspond to the behavior of ML records, and I
was explicitly *not* trying to duplicate the behavior of ML records.
When this need is combined with the need for unboxing, a syntax for
field reference quickly becomes desirable. This motivates field names so
that we can write things like "a.b".

At the highest level, my belief is that our model for named types should
be based on name equivalence. In this sense, we should view a tuple as a
degenerate, unnamed record. That is, given

	(defstruct s i:int c:char)

then

	(let ((tup-instance (ref (5:int, #\a)))
	      (s-instance (s 6 #\b)))
	  (set! tup-instance s-instance))

should be legal (though I am not convinced that I have all of the
unboxing right). That is, when we write the tuple:

	(int, char)

we are really writing 

	(defstruct _ _:int _:char)

[Aside: should the elements of the defstruct be within parentheses? I
think that perhaps the answer should be yes.]

> It is not possible to have both of the following correctly:
> i) Field ordering as a defining character of record type
> ii) Record polymorphism with inferred record types
> 
> Consider the following:
> 
> function x ->  x.a + x.b

Let's try to give more complete examples so that we can really look at
them. I think you are concerned with something like:

	(defstruct s1  a:int  b:float c:int)
	(defstruct s2  a:int  m:float n:float c:char)

Note that in these structures, the 'c' members disagree on both position
and type. Now the question you pose is: "what is the type of 'x' in:"

	(defun f x (x.a + a.b))

It would seem that there are two possibilities here:

1. By filtering against field names, the inference engine concludes that
the type must be either s1 or s2, but it cannot uniquely resolve the
type. Automatic type resolution therefore fails, and the user is
required to specify the type explicitly, as in:

	(defun f x:s1 (x.a + a.b))

2. The inference engine concludes that the type must be either s1 or s2,
and is not unique. We resolve this by polyinstantiating f.

In abstract, I think that the preferred answer is probably (2), but I
don't understand what implications this may have when 'f' is later used
as a procedure parameter. What am I missing?


-- 
Jonathan S. Shapiro <shap at eros-os.org>