[MLton] upcoming release

[Matthew Fluet]

> > One other unresolved issue is whether or not to include an _address
> > primitive, and what its annotation should be.
> ...
> > Wesley has rightly pointed out that the current implementation prohibits 
> > taking the address of a function from the ML side, except by lying about 
> > the type of the object.
> 
> I agree that the current situation is bad.  And it seems like
> 
>   _address "symbol": ptrTy;
> 
> is the way to go, since it jibes with the MLton assumption that all
> pointers are the same size.

That's good with me.

> As to whether we then drop the _address component of _symbol, I am now
> fine either way.  I did find the fact that _symbol * returned three
> components confusing.

_symbol * only returns two components -- the getter and the setter.  
_symbol "symbol" returns three components -- the address, the getter, and 
the setter.  I'm also agnostic about the _address component of _symbol.  
One agument for dropping it is that one needs to do:

 val () = (_export "foo": int -> int;) foo
 val fooAddr = _address "foo": MLton.Pointer.t;

to get the address of an exported function, so there is a seeming symmetry 
for needing

  val (get,set) = _symbol "foo" alloc: int;
  val fooAddr = _address "foo": MLton.Pointer.t;

to get the address of an allocated value.

> > Also, I still wonder if "define" is the right name for the annotation that 
> > indicates that the symbol should be (statically) allocated by the ML 
> > object code.  How about "storage"?
> 
> How about "alloc" or "allocate"?

I slightly prefer "alloc".