[MLton] Re: [MLton-devel] MLton HOL

[Stephen Weeks]

> Also, the following example now fails:
> 
> longbottom:~$ mlton
> MLton 20031018 (built Sun Oct 19 21:07:11 2003 on longbottom.lotr)
> longbottom:~$ cat t.sml
> signature Foo = sig val f : ('a -> 'a) -> 'a -> 'a end
> structure Foo :> Foo = struct fun f g x = g x end
> fun g x = []
> val z = Foo.f g ([] : int list)
> longbottom:~$ mlton t.sml
> Error: t.sml 4.1: unable to infer type for z
>    type: ??? list
>    in: val z = Foo.f g ([]: int list)
> compilation aborted: elaborate reported errors
...
> The example is a very cut-down version of a real program implementing
> parser combinators. Here mlton should be able to deduce the type of
> the final result z, but seems to be ignoring the signature of Foo.

Yeah.  This is a known problem with the new front end.  Your
conclusion that MLton is ignoring the signature is completely correct.
This experimental release has proper typing checking for core-level
constructs only, not for modules.  We're working on the module stuff.

The problem is that the type of f is more general than the constraint
in the signature.  Hence, MLton, which only knows the more general
type, cannot deduce a type at the application of Foo.f, and therefore
throws up its hands due to the value restriction.  The easiest fix,
until we have a completely working front end, is to constrain f when
it is defined.

	fun 'a f (g: 'a -> 'a) (x: 'a): 'a = g x

Hopefully this only comes up in a couple of places (I think I hit
maybe 2 in all of MLton).

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