[MLton] Callback to function pointer?

[Stephen Weeks]

> I think the currying is very useful here, because the common scenario is 
> what appears in examples/ff/iimport.sml:
> 
> local
>    val double_to_double =
>       _import * : DynLink.fptr -> real -> real;
>    val sin_fptr = DynLink.dlsym (hndl, "sin")
>    val cos_fptr = DynLink.dlsym (hndl, "cos")
>    val tan_fptr = DynLink.dlsym (hndl, "tan")
> in
>    val sin = double_to_double sin_fptr
>    val cos = double_to_double cos_fptr
>    val tan = double_to_double tan_fptr
> end

I don't disagree, but I will point out that even in this case
uncurried isn't so bad.

local
   val double_to_double =
     fn sym => fn r => _import * : DynLink.fptr * real -> real; (sym, r)
   val sin_fptr = DynLink.dlsym (hndl, "sin")
   val cos_fptr = DynLink.dlsym (hndl, "cos")
   val tan_fptr = DynLink.dlsym (hndl, "tan")
in
   val sin = double_to_double sin_fptr
   val cos = double_to_double cos_fptr
   val tan = double_to_double tan_fptr
end

It just goes along with my principle that currying is a fine shorthand
when used locally (I do it all the time), but should only be exposed
in an interface when there is staged computation.

> > Stephen proposed:
> > 
> >  _symbol "symbol": cbTy;            (unit -> cbTy) * (cbTy -> unit)
> >  _symbol *: ptrTy, cbTy;            (ptrTy -> cbTy) * (ptrTy * cbTy -> unit)
> 
> My vote is for this proposal.  

OK.  I'm happy enough.  Hopefully Wesley and others don't find it too
bad.

> > One thing I don't like about any of the proposals is having to write
> > the pointer type, since it is almost always MLton.Pointer.t.  
> 
> I disagree.  DynLib would like to use an opaque DynLib.fptr.

True.