[MLton] Callback to function pointer?

Wesley W. Terpstra wesley@terpstra.ca
Fri, 15 Jul 2005 23:40:45 +0200

Very nice summary!

On Fri, Jul 15, 2005 at 12:26:37PM -0700, Stephen Weeks wrote:
> I looked back over all the proposals, and tried to unify them as much
> as possible so we could compare the remaining differences.  Here's
> what they have in common.
>  _address "symbol": ptrTy;	    ptrTy
>  _import "symbol": cfTy;	    cfTy
>  _export "symbol": cfTy;	    cfTy -> unit

Actually, I proposed breaking backwards compatibility in one place:
_export "symbol": cfTy -> unit;     cfTy -> unit

> Further, I think there is a benefit to the concision of not having to
> write out the whole type (especially in my proposal, where it would be
> silly to).

I agree that it is longer to type.
However, if you use type inference, you don't have to type it at all.
Moreover, should our goal be brevity ... or clarity?

> Since we already don't match the type annotation with _export, I don't
> think it's a huge deal to continue that trend.

You will notice that even members of this list are confused by what 
_export actually does. This has not been a problem for _import.

I think the reason people are confused by _export is *because* the
type annotation does not match the expression. Including the unit ->
shows people that this is a function taking a function. 

> BTW, as a reminder, my proposal easily expands via an annotation if we
> want to define the C base type SML side.
>  _symbol "symbol" define : cbTy;    (unit -> cbTy) * (cbTy -> unit)

Well, the equivalent in my solution was:
_export "symbol": cbTy -> unit;		cbTy-> unit

I think this is fairly consistent.

> Wesley's suggestion of using type inference would be nice here.  This is
> an interesting idea, and, I can't see any reason why it wouldn't work.

This is, after all, an extension to SML. ;)

Wesley W. Terpstra