[MLton] upcoming release

[Stephen Weeks]

> 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.

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.

> 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"?