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

[Matthias B. <bl...@re...>]

Andrew Kennedy wrote:
> 
> Andreas,
> 
> Whatever the glitches in the Definition, as a user of SML
> as well as an implementer I would like to see fewer of
> my programs rejected by the type-checker. In particular, I
> dislike the fact that some implementations won't accept
> 
> structure STR :> SIG = struct
> 
>   val settings = ref []
> 
>   ...
> 
> end
> 
> despite the constraints on "settings" imposed by the rest
> of the structure ("...") or the signature SIG.
> 
> Furthermore, I find it unpleasant that the typing of a
> program might be influenced by the presence of a semicolon
> separator which otherwise can be regarded as optional.
> 
> There are two questions:
> 
> (1) What does one do about types that are still "undetermined"
> at the level of the unit-of-compilation (e.g. "..." or "SIG"
> above do not resolve the type of "settings"). Instantiating
> with something arbitrary (e.g. unit) is just too confusing so
> I would vote for rejecting such programs as ambiguous.
> 
> (2) What does one do in a top-level-loop environment?

I share these thoughts.

Here is my take on it:

1. What is a topdec?

   Important case: programs consisting of several separately compiled
   compilation units (e.g., ML source files):

      A topdec is the contents of the _entire_ compilation unit (i.e.,
      regardless of any semicolons within).

   Less important case: interactive toplevel:

      I don't really care about this one, but I'd say that topdecs are
      separated by semicolons as they are now.

2. Important design decision: No free type variables may "escape" a topdec.
   
   While in an interactive setting one can imagine such free type variables
   to be bound "later" depending on how the values in question get used,
   this is not acceptable in the separately compiled case.  The reason being
   the fact that different compilation units might (try to) bind such a free
   type variable differently, which would require tedious and non-obvious
   additional bookkeeping  which does not follow traditional notions of
   dependency.

3. Reject topdecs as late as possible: I find the current behavior of SML/NJ
   extremely unpleasant.  This is along the lines of Andrew's signature
   constraint example above and many of the other examples that people have
   been giving in this thread.

Matthias