[MLton] Question about Definition of SML :)

[Anoq of the Sun]

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