[MLton] syntax error for "_address"

Matthew Fluet fluet@cs.cornell.edu
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" : 
> MLton.Pointer.t;
> 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 
right then.

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.