[MLton-user] opaque types and ffi

[Anoq of the Sun]

Matthew Fluet wrote:
> The short answer is no.  Once you use an opaque signature match, the type
> becomes abstract and the type checker will refuse to pass an abstract type
> to an ffi function.

The longer answer... :) Is that you could make all your pointer
operations in a structure which you make opaque signature match
for. If you do all ffi calls inside the structure you
can give the internal type to the ffi-stuff and it
will work just fine. But you can't pass
it to ffi functions outside the structure
(unless you have functions in your structure
to convert it to and from the internal type -
but that partly violates the idea of opaque matching -
except that you still have the type-safety where you
don't use those conversion functions you might
declare).

I have exactly the same problem in my SDL-bindings
by the way. I hide an SDL_Surface * in C as
SDL.Surface.T in ML with opaque matching (this is
in my still-unreleased version of SDL::ML).
And I have to supply conversion functions to
pass it to e.g. an SMPEG module or an SMJPEG
module.

I have seen in a resaerch article somewhere
(can't remember which one right now) that
this is claimed to be a problem with type-safety or
opaque signature matching. In my opinion it is
just a weakness of the ML module system that
you cannot "reopen" a structure to add more
functionality to it and then "close" it again.
You can do this with namespaces in C for
example. But of course C is such a messed up language
anyway w.r.t. type-safely and namespaces
doesn't have any notion of opaqueness so that's
why it doesn't give problems here.

I'm thinking of looking into extending / modifying
the ML module system to accomodate this
some time. I haven't looked at all the details
of the semantics yet but to me it seems to be
possible to do this.


Cheers
-- 
http://www.HardcoreProcessing.com