Re: [MLton-user] Type inference in structure not using signature constraint

On Thu, Aug 9, 2012 at 10:06 AM, Matthew Fluet <[email protected]> wrote:
> I believe that MLton is using the largest enclosing core-level
> declaration as the boundary to resolve both flexible records and
> overloaded constants/values.  But, it looks like it would be easy
> enough to batch up the overloads to a larger context; it might be that
> signature matching assumes that there are no unresolved flexible
> record types or overloaded constants/values in the matched
> environment, but it might work.

I've committed a new MLB annotation that changes the scope at which
overloads and flexible records are resolved:
  http://mlton.svn.sourceforge.net/viewvc/mlton?view=revision&revision=7618

"resolveScope dec" resolves at the smallest enclosing dec, which is
generally a smaller context than is used by other compilers.  For
example, both SML/NJ and Poly/ML accept:

  val a : Int32.int = let val b = 1 in b end

but, with "resolveScope dec", MLton will not accept:

  val a : IntInf.int = let val b = 1 in b end


On the other hand, "resolveScope strdec" resolves at the smallest
enclosing strdec, which is generally a larger context than is used by
SML/NJ.  For example, SML/NJ rejects:

  structure S = struct val a = 1  val b : IntInf.int = a end

but, with "resolveScope strdec", MLton will accept:

  structure S = struct val a = 1  val b : IntInf.int = a end

because MLton treats the sequence of "val ..." declarations as part of
the same strdec.  With "resolveScope strdec", MLton will reject:

  structure S = struct val a = 1  structure T = struct end  val b :
IntInf.int = a end

because the intervening structure declaration forces the two "val ..."
declarations into different strdecs.  On the other hand, with
"resolveScope topdec", MLton will accept the program.

SML/NJ's resolution strategy seems to be somewhere between MLton's
"resolveScope dec" and "resolveScope strdec", possibly due to the
ambiguity in sequences of decs and sequences of strdecs.

Poly/ML accepts both:

  structure S = struct val a = 1  val b : Int32.int = a end

and

  structure S = struct val a = 1  structure T = struct end  val b :
Int32.int = a end

Poly/ML also accepts:

  signature A = sig val a : Int32.int end
  structure S = struct val a = 1 end
  signature B = sig end
  structure T :> A = S

but, with "resolveScope topdec", MLton rejects

  signature A = sig val a : IntInf.int end
  structure S = struct val a = 1 end
  signature B = sig end
  structure T :> A = S

With "resolveScope program", MLton will accept the program.

MLton's handling of topdec may be slightly different than specified by
the Definition.  Effectively, "resolveScope topdec" will check
resolution after each sigdec, strdec, and fundec.  Furthemore, it is
never the case that a topdec strdec is elaborated immediately after
another topdec strdec; consecutive topdec strdecs are coalesced into a
single strdec.  Hence, smallest enclosing topdec implies largest
enclosing strdec.  "resolveScope program" will check resolution after
a sequence of sigdecs, strdecs, and fundecs from a single file.

Poly/ML's resolution strategy seems to be somewhere between MLton's
"resolveScope topdec" and "resolveScope program".  At least in the
REPL, Poly/ML seems to combine as many sigdecs, strdecs, and fundecs
that are not separated by ";".  I think that would correspond to the
largest enclosing topdec.

Note that "resolveScope" does not affect the resolution of type
variables that are constrained to be monotypes by the value
restriction.  (See the second example at the top of
http://mlton.org/TypeChecking.)  The issue with using "resolveScope"
for this resolution is that MLton's current behavior is to resolve
those at the smallest enclosing topdec, not the smallest enclosing
strdec.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/