[MLton] building mlton on Snow Leopard

[John Reppy]

I understand the source of the error, but what is the correct type  
here so that I can
fix it?  A debate about the interpretation of the SML'97 semantics is  
not useful (even
though I actually agree with your position).

	- John

On Sep 17, 2009, at 10:16 AM, Matthew Fluet wrote:

> On Thu, 17 Sep 2009, John Reppy wrote:
>> I'm trying to compile mlton (revision 7228) using the command
>>
>> 	make TARGET_ARCH=x86_64 smlnj-mlton
>>
>> on Snow Leopard, but I'm hitting type errors in ssa/combine- 
>> conversions.fun
>
> Nothing to do with Snow Leopard.  Everything to do with SML/NJ using  
> an overly restrictive context for type inference.
>
>> ssa/combine-conversions.fun:57.5-58.60 Warning: type vars not  
>> generalized because of value restriction are instantiated to dummy  
>> types (X1,X2,...)
>
> The code in question is:
>
> val { get, set, ... } =
>   Property.getSetOnce (Var.plist, Property.initConst NONE)
>
> Yes, the type of NONE (and get and set) are undetermined by this  
> declaration.  However, subsequent use of get and set within the  
> module determine the types.
>
> For a smaller example:
>
> structure S =
> struct
>   val z = (fn x => x) []
>   val y = z :: [true] :: nil
> end
>
> Accepted by MLton, Poly/ML, and HaMLet; only rejected by SML/NJ.
>
> Another example:
>
> structure S : sig val z : bool list end =
> struct
>   val z = (fn x => x) []
> end
>
> Accepted by MLton, Poly/ML, and HaMLet; only rejected by SML/NJ.
>
>
> Admittedly, we have attempted to keep the MLton sources compatible  
> with SML/NJ, so we will probably put in an explicit type constraint  
> (you'll see such a constraint in most uses of Property.* functions),  
> but it's really SML/NJ's bug.
>