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

[Robert H. <Rob...@cs...>]

I think implementations differ on the top-level.  NJ instantiates the free
type variables to a hidden type.  One reason to do this is to make it more
convenient to use the top level as a "calculator".  eg, students find it
confusing (and many find it peculiar) if evaluating "nil" is OK, but "nil @
nil" is rejected because of some incomprehensible type error.  The NJ
approach means that "nil @ nil" evaluates (to nil!) but with a weird-looking
type.  The value is not much use, however, because of the hidden type.

The possibility to use signature information to constrain declarations has
often been suggested, but it is difficult to put into practice.  For
example, as you go along processing a structure, a binding for x might later
be shadowed, so any constraint on x's type in the signature would not affect
the earlier one.  This makes it tricky to try to simultaneously type check a
structure and impose a signature on it.  Thus most implementations that I am
aware of opt for synthesizing the principal signature of the structure, then
matching it against the target signature.  However, this can have an
unpleasant effect of the kind you mention.

Bob

-----Original Message-----
From: Andrew Kennedy [mailto:ak...@mi...]
Sent: Wednesday, September 26, 2001 9:34 AM
To: Andreas Rossberg; sml...@li...
Subject: RE: [Sml-implementers] Free type variables on toplevel


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? 

- Andrew.


_______________________________________________
Sml-implementers mailing list
Sml...@li...
https://lists.sourceforge.net/lists/listinfo/sml-implementers