[MLton-user] opaque types and ffi

[Tom 7]

It might be nice to have a "MLton.void32" (just kidding ;)) type that had
no operations or ML inhabitants, but which was represented as a 32-bit
word and could be used to encapsulate C pointers and passed to/from the
FFI. I don't mind using SysWord.word within my FFI modules since I'm doing
so much unsafe stuff anyway, but it is a little strange that I can xorb
them!

 - Tom

> 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
>
> _______________________________________________
> MLton-user mailing list
> MLton-user@mlton.org
> http://www.mlton.org/mailman/listinfo/mlton-user
>
>


[ NEW! : http://tom7.org/       ]
[ OLD! : http://fonts.tom7.com/ ]