building mlton on Snow Leopard

[John Reppy]

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

ssa/combine-conversions.fun:57.5-58.60 Warning: type vars not  
generalized because of
    value restriction are instantiated to dummy types (X1,X2,...)
ssa/combine-conversions.fun:64.21-64.46 Error: operator and operand  
don't agree [tycon mismatch]
   operator domain: ?.S.t * ?.X1 option
   operand:         ?.S.t * (('Z * 'Y * {signed:'X}) * 'W) option
   in expression:
     set (x3,SOME conversion)
ssa/combine-conversions.fun:68.7-76.20 Error: case object and rules  
don't agree [tycon mismatch]
   rule domain: ((?.S.t * 'Z * {signed:bool}) * 'Y) option
   object: ?.X1 option
   in expression:
     (case (get x2)
       of NONE => stop ()
        | SOME (prev  as (<pat>,<pat>)) =>
            if (<exp> <= <exp>) andalso (<exp> <= <exp>)
            then loop prev
            else if <exp> andalso <exp>
                 then loop <exp>
                 else if <exp> then <exp> else <exp>)
ssa/combine-conversions.fun:93.10-100.21 Error: case object and rules  
don't agree [tycon mismatch]
   rule domain: ((?.S.t * ?.S.t * {signed:bool}) * ?.S.t) option option
   object: ?.X1 option Option.t
   in expression:
     (case (Option.map (var,get))
       of SOME (SOME (<pat>,<pat>)) =>
            if WordSize.equals (<exp>,<exp>)
            then Var x2
            else PrimApp
                   {args=Vector.new1 <exp>,prim=Prim.wordExtdToWord  
<exp>,
                    targs=Vector.new0 <exp>}
        | _ => exp)


_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Matthew Fluet-5]

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.

_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[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.
>

_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton

[Matthew Fluet-5]

val { get : Var.t -> ((WordSize.t
                        * WordSize.t
                        * {signed:bool})
                       * Var.t) option,
       set, ... } =
    Property.getSetOnce (Var.plist, Property.initConst NONE)

Committed as r7229.

On Thu, 17 Sep 2009, John Reppy wrote:

> 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.
>>
>
>
> _______________________________________________
> MLton mailing list
> MLton@...
> http://mlton.org/mailman/listinfo/mlton

--
============================================
Matthew Fluet
Assistant Professor
Department of Computer Science
Rochester Institute of Technology
102 Lomb Memorial Drive
Rochester, NY 14623-5608
Tel: [phone] ; Fax: [phone]
mtf@... ; http://www.cs.rit.edu/~mtf
============================================
CONFIDENTIALITY NOTE: The information transmitted, including attachments,
is intended only for the person(s) or entity to which it is addressed and
may contain confidential and/or privileged material.  Any review,
retransmission, dissemination or other use of, or taking of any action in
reliance upon this information by persons or entities other than the
intended recipient is prohibited.  If you received this in error, please
contact the sender (mtf@...) and destroy any copies of this
information.

_______________________________________________
MLton mailing list
MLton@...
http://mlton.org/mailman/listinfo/mlton