[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