[MLton] syntax error for "_address"

[John Reppy]

Thanks for the info.  Is there likely to be a new snapshot of MLton  
soon?  Also, what is the best way
to package up an SML "library" that depends on generated C code  
(because of _export) and C libraries?
Can the MLB tool support the steps of generating, compiling, and  
linking the C code?

	- John

On Nov 2, 2005, at 9:54 AM, Matthew Fluet wrote:

>
>> 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.
>