[MLton] syntax error for "_address"
Wed, 2 Nov 2005 10:54:43 -0500 (EST)
> I'm getting the error
> Error: glut.sml 130.28.
> Syntax error: replacing WILD with ASTERISK.
> where line 130 is
> val glutCreateMenuCB = _address "glutCreateMenuCB" :
> I'm using the MLton command
> mlton -default-ann 'allowFFI true' -stop tc -export-header glut-
> glue.h glut.sml
> with version 20050731. Was "_address" added since 20050731?
Yup, we were in the process of a major overhaul of the FFI system right
around that time, and I don't recall why we did an experimental release
In any case, at that moment in time, we had attempted to roll the
functionality of _address into _symbol with the following syntax:
_symbol "C variable name" attr... : cPtrTy, cBaseTy;
which elaborates to an expression of type
cPtrTy * (unit -> cBaseTy) * (cBaseTy -> unit)
So, you can get the functionality of _address using:
#1 (_symbol "sym" : MLton.Pointer.t, char;)
That was not a very happy point in the design space.
We ended up moving away from this in two directions.
First, we unified all the ffi primitives so that the type annotation is
the same as the elaborated type. We concluded that if it lookslike a type
annotation, then it should act like a type annotation. This can cause
some extra verbosity. For example, the current syntax for _symbol seems
to require you to mention cBaseTy twice. However, the annotation is just
an arbitrary type, which is elaborated before we inspect its form, so you
can use a type abbreviation to ease your burden.
Second, we noted that there appeared to be sufficient cases where one
wanted the address of a C object for which a getter/setter would not be
appropriate. For example, when taking the address of a C function, you
need to cook up some bogus cBaseTy for the getter and setter. It seemed
to make more sense to allow taking the address of an arbitrary C symbol
without needing to delude ourselves into thinking that it necessary
corresponded to a mutable cell of storage.