[MLton] Question about Definition of SML :)
Anoq of the Sun
anoq@HardcoreProcessing.com
Wed, 03 Dec 2003 13:40:25 +0200
Stephen Weeks wrote:
> I don't see how exceptions can cause problems with this stuff, since
> exception declarations don't generate new type names, they just add
> new variants to the exn datatype. The rules in the dynamic semantics
> that allocate new exception names (dynamically) prevent exceptions
> from going wrong.
Ah, OK!
> val _ =
> > let
> > val x = ref []
> > datatype a = B
> > val _ = x := [B]
> > in
> > ()
> > end
> > val x = ref []
> >
> > This violates the value-restriction.
>
> No. Without the side condition on rule 14, x can be assigned the
> monotype "a list ref", so the value restriction does not come in to
> play.
I can see now that this is because of the nested val. Writing
val x = ref []
alone fails in SML/NJ due to value-restriction.
but writing
val _ = let val x = ref [] in () end;
Is OK.
So assuming that the SML/NJ behaviour is correct,
I can't see why this is OK though?
I thought I understood the scoping rules for type variables
but I can't see what's happening here. Can you explain this? :)
> > > val rec f =
> > > fn x =>
> > > let
> > > datatype A = C of bool -> bool
> > > in
> > > fn C x => x true
> > > end
>
> If you change the circle to circle-plus, then one could make the type
> name for A avaiable when elaborating "fn x => ...", but then the side
> condition on (26) would rule out the elaboration of the "rec f =
> ..." because the type name for A would be in VE but not in T of C.
OK - I think I finally got this one! :)
Cheers
--
http://www.HardcoreProcessing.com