flexible records

[Stephen Weeks]

> Isn't  the  reason  that flexrecord2 succeeded simply that the principle type
> for g is
>     { foo: 'a } -> 'a
> It would be pretty bad if this were rejected since clearly  if  I  explicitly
> typed g it would have to be accepted.

No.  The "principal type" of g is
	{ foo: 'a, ... } -> 'a

> Thus  I  claim  (but not looking at the definition) that all of your examples
> should  be  accepted.   (I  can't  imagine  that  the  standard  would  allow
> flexrecord2  and  yet  not  allow  both flexrecord3 and flexrecord4.)  What's
> going on with MLton on this?

I believe the Definition allows all of them to be accepted.  I also believe the
definition allows all of them to be rejected, because of comment (1) on the
bottom of page 27, which states

	For each occurrence of a record pattern containing a record wildcard,
	the program context must uniquely determine the domain of its row type.

Well, as with overloading, the question is, what context is applicable.  Is it
the whole program, the nearest enclosing dec, the nearest enclosing topdec ...?

MLton should be able to flexrecord, flexrecord2, and flexrecord3 (it can't yet,
but I'm working on it).  But flexrecord4 is really hard, and I don't see how to
get it.  The problem is that at the point of defining g, you need to generalize
a component of the flexible part of the record.  That is, you need the type of g
to be

	{ foo: 'a, goo: 'b } -> 'a

I don't see how to do this without looking ahead.  But you can't look ahead
until you've decided how g is generalized.  This is my guess why the Kit and
Moscow ML get 2 and 3, but not 4.  And why it looks like MLton will be the
same.

> Unrelated to this, any conclusions on Norman's bug?

about to check in the fix