[MLton] Callback to function pointer?

[Matthew Fluet]

> > There is also the incongruity that the annotation on _store/_export does 
> > not correspond to the type of the elaborated expression, but rather a 
> > particular component of the type.
> 
> So, you are suggesting that the stuff after the ':' should be exactly the
> type which is returned? That makes sense, I didn't think of it that way.

I was simply making a comment.  I believe that in the past people have 
been slightly confused about _export because the type of the expression 
doesn't match the annotation.

> Personally, I think the above interface is a lot simpler than the one you
> propose below. There's only four keywords, each does exactly what it says.

Again, just our difference of opinions.  They do what they say, _depending 
on what you give it_.

> > I'll also point out that the MLton.Pointer structure does have an 
> > advantage over _store*/_import* in that the MLton.Pointer functions allow 
> > for an offset from the base pointer, giving efficient access to C arrays.
> 
> However, because you can use MLton.Pointer.add, you can just add to the
> pointer, getting a new pointer, and then use that for _import. Surely any
> difference here is just a local optimization? ;-)

You would have to use it with _import *, but yes, I agree that it is 
ultimately the same.

> I see that there is a distinction in the implementation of _import/_export
> between arrow and non-arrow types, but why does this distinction matter to
> the user? Does it need to be visible beyond the type signature?
> 
> Give me an example of how I might shoot myself in the foot.

Oh, in either case the type system will keep you from doing something 
really stupid.  In fact, your most likely to get burned due to the weak 
type checking of linked object files, where you _import "foo" as an int, 
but the C code exports "foo" as a function.

> > I admit that leaves _import * as somewhat of an outlier; it is a
> > relatively new feature and I could imagine giving it a distinguished
> > primitive.
> 
> What do you mean an outlier? _store * also uses a pointer.
> Or do you mean to omit _store *?

I just mean that _fetch/_store make an nice pair, each with * version.  
There is no _export *, so it makes _import * seem a little out of place.  
I'm just a sucker for symmetry.

> > The only reason to export in the first place is to interface with C, and
> > if you already have C code lying around why not declare the objects there. 
> 
> Another good point.
> However, sometimes the C code is a library you are wrapping.
> 
> If it is possible to get away with no C other than linking the library, I
> think this has some benefit, maybe not much.

Agreed, but the question remains: are the C libraries that expect the 
client code to provide a particular exported symbol?

> For symmetry, why not:
> _store * : ptrTy -> cbTy -> unit;    : ptrTy -> cbTy -> unit
> _store "symbol":    cbTy -> unit;    :          cbTy -> unit
> 
> I see these benefits:
>   1. * means prepend a "ptrTy ->" in all cases
>   2. the type after the ':' is always the type of the expression
>   3. _store * when curried with _address "sym" is the same as _store "sym"
>     (like _fetch * curried with _address "sym" = _fetch "sym")

Those are good points.  I just know that it is a long, uphill battle
getting curried functions past Stephen. ;-)