Re: [Sml-implementers] Free type variables on toplevel

[Andreas R. <ros...@ps...>]

Peter Sestoft wrote:
> 
> However, it is confusing (and probably a mistake) that Moscow ML
> currently accepts free type variables in structure declarations in the
> interactive system:
> 
>    - structure S = struct val i = rev o rev end;
>    ! Warning: Value polymorphism:
>    ! Free type variable(s) at top level in structure identifier S
>    > structure S : {val i : 'b list -> 'b list}
> 
> Note that 'b in the type of S.i is not universally quantified.

IMHO the confusion could be reduced by not using ordinary type variable
syntax for reporting "undetermined types".

But apart from such cosmetics, the behaviour of Moscow ML's toplevel is
absolutely reasonable, IMO. And I believe, as I tried to explain in my
post, that strict reading of the Definition does not allow any other
behaviour (although that might not have been the intention of the
authors).

OTOH, for compilation units, Andrew's proposal and Moscow ML's approach
of rejecting undetermined types seems the only sensible thing to do.
This is something that has to be specified along with the separate
compilation mechanism. I even think it should be enforced that every
compilation unit has a syntactic signature (i.e. one that can be
expressed within the language, precluding e.g. hidden types etc.).

> The question of how much context to take into account has existed for
> years, namely, when resolving operator overloading and flex records.
> The Definition only specifies that at most the enclosing
> structure-level declaration should be taken into account.

For flexible records the Definition does not even say that the context
for resolving it might be limited by an implementation, although
unrestricted context is incompatible with let polymorphism. This
arguably is more or less a bug. In any case I strongly vote for fixing
any such source of implementation-dependent behaviour. The natural
choice in the case of overloading and flexible records seems to be the
smallest enclosing value declaration.

	- Andreas