Phil,
I don't think your test-1.sml is correct Standard ML. If you cut it right down
to:
type ('a, 'b) t = 'b;
fun mkT n = (n : ('a, int) t);
val x = mkT 2;
You will find that Poly/ML says:
Warning-The type of (x) contains a free type variable. Setting it to a unique
monotype.
val x = 2: (_a, int) t
and SML/NJ says:
Warning: type vars not generalized because of
value restriction are instantiated to dummy types (X1,X2,...)
val x = 2 : (?.X1,int) t
What is happening here is that if x is given it most general type based on the
right-hand side of the binding, then the binding is illegal so the compilers
are generating a dummy monomorphic type to let it get through.
If you try it with an explicit type constraint as in:
val y : ('a, int) t = mkT 2;
both compilers will correctly raise an error.
The problem is the so-called "value restriction" (see
http://users.cis.fiu.edu/~smithg/cop4555/valrestr.html). Since the right-hand
side for your value binding for x involves a function call, and its type
contains a free type variable, the value restriction disallows it. It seems
when you wrap this up with the type constraints in signatures and the bindings
in structures, the problem shows up at a different level and the error messages
are a bit misleading, but the fundamental issue is that ML won't give x defined
as you have defined it a polymorphic type.
Tip: with problems like this, it is often helps to see what happens with fewer
signature constraints. Your example goes through with a warning if you remove
the signature constraint on structure B - and it is that warning that explains
why it can't work with the signature constraint.
Regards,
Rob.
(e.g., see http://users.cis.fiu.edu/~smithg/cop4555/valrestr.html)
On 21 Jul 2012, at 10:53, Phil Clayton wrote:
> Apparently the plain text attachments didn't work for everyone (and they're
> not very readable via the list archive) so here they are again, this time as
> a binary blob.
>
> Phil
>
>
> On 20/07/12 14:49, Phil Clayton wrote:
>> I have been making use of phantom types (for encoding a
>> single-inheritance class hierarchy) and have encountered a case where
>> code accepted by MLton does not type check with Poly/ML. After
>> investigating, it appears that MLton, Poly/ML and SML/NJ all take
>> different views on what is a valid program!
>>
>> Attached are two small examples with a slight difference where type
>> checking accepts/rejects as follows:
>>
>> test-1.sml test-2.sml
>>
>> MLton 20100608 accept accept
>> Poly/ML 5.4, latest reject accept
>> SML/NJ 110.73 reject reject
>>
>> I don't know which of the above is consistent with the Definition yet.
>> (I would be very glad if test-1 is a legal program though!)
>>
>> Phil
>>
>>
>> _______________________________________________
>> polyml mailing list
>> [email protected]
>> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
>>
>
>
> <tests.tar.gz>_______________________________________________
> polyml mailing list
> [email protected]
> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
