[MLton] implement _address and _symbol

[Stephen Weeks]

> One approach might be to deprecate ': ...;'. Continue to accept it
> for _export, _import, and _import *, but issue a warning. Then,
> using type inference, determine the pointer type used for _import *.

We might do this if we find the type-inference approach works.  But
we're not there yet.

> If I am going for the type-inference route, then the _symbol keyword
> becomes less appealing. This is because you have to write a big mess
> for actual type signature if you want to document the val's type (a
> good habit IMO).

Nonsense.  You only have to write what you need.  E.g.

  val get: unit -> int = #1 (_symbol "x")

> Stephan's _symbol suggestion is perhaps shorter if you need both:
> 	val (get, set) = _symbol "x"
> vs
> 	val (get, set) = (_fetch "x", _store "x")
> However, it's not a lot shorter.

But one doesn't duplicate the symbol name, which is a good thing.  And
it's not hard to write #1 or #2 if you just want the getter or setter.

> When you (sanely) document the type, the _symbol method is hard to read:
> 	val (get : unit -> int, set : int -> unit) = _symbol "x"
> vs
> 	val get : unit -> int = _fetch "x"
> 	val set : int -> unit = _store "x"

I see no difference here.  But if you care,

        val s = _symbol "x"
 	val get : unit -> int = #1 s
 	val set : int -> unit = #2 s

Again, avoiding duplication of the symbol name is good.

> (* Fails to compile (cannot export polymorphism): *)
> val () = _export "id" (fn x => x)

This points out a problem with the type inference approach.  MLton
will quite happily infer the type "unit -> unit" for "fn x => x", in
which case the export may succeed.

> We seem to have settled on
> 
> _symbol *: ptrTy, cbTy;  ==> (ptrTy -> cbTy) * (ptrTy * cbTy -> unit)

Yes, let's go with this.  I have not yet been convinced of any
problems with it.

> This isn't a real suggestion, but one could imagine the following syntax:
> 
>   _symbol[cbTy] "symbol";
>   _symbol[ptrTy,cbTy] *;
>
> which makes it a little more clear that the type annotation is selecting a 
> particular primitive

Cute.

> I still prefer _symbol over _fetch/_store.

Me too.

> I don't mind that a 'define'-ed _symbol is not initialized; this is *C* 
>   and that behavior is allowed.

Not requiring initialization seems better to me.

> I don't think that type-inference is necessary; I think the current 
>   annotations are fine.  Also, whatever decision is reached wrt 
>   type-inference, it would certainly make more sense to first implement 
>   the new FFI with annotation before tackling inference as well.

Definitely.  Doing both the new keywords and dropping the type
annotations is too much.  Let's do just the new keywords first.