[MLton] syntax error for "_address"
Wed, 2 Nov 2005 10:07:39 -0600
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?
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" :
>> 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.