Alastair Reid wrote:
[...] ps I have a feeling of feeping creaturism as I watch this list - a nice simple design seems to be getting more complex.
Could you elaborate on this? The basic FFI *is* still nice and simple IMHO.
I'm thinking of: 1) Trying to support a complex language like Java in the same design (or in any design, really) My sense is that this will gradually infect the ffi design with the complexities of the other language and that this effect will be worsened by the mismatch between the two type systems. 2) Moving library specs, etc. out of the individual ffi decls. This seems to be partly motivated by supporting Java and partly by convenience and a dislike of cpp.
Mentioning plain Addr in it was a design mistake because:
* Pointers to code and data need not have the same size.
I understand this argument though I'm not sure which architectures this applies to. Alphas?
* The extra type parameter in Ptr/FunPtr tremendously helps to resolve overloading ambiguities. * Addr doesn't carry any type information, so there is no help at all from the type checker, which is even worse than C.
I remember briefly using the same trick in the early greencard days but gave up on it because I found myself wanting a many-to-many relationship between C types and Haskell types and using overloading and an extra type parameter I could only get a one-to-many relationship. (This is what greencard's DIS's give you.) So I've been sitting here wondering how things are turning out in practice. For example: How often do you have to create two Haskell types which really ought to be just one type just so that you can use the overloading? Is pointer arithmetic on Ptr's useful? (It's obviously useful for arrays but can you use it (safely and portably) to access fields of structs or do you have to add an explicit byte count to get predictable/safe results.) What's the preferred way to represent an opaque C data type which happens to be a pointer? With Addr, I'd use: newtype AbstractFoo = MkAbstractFoo Addr Should I use Ptr () instead? What libraries is the evolving design being tried out on (I know about your OpenGL library).
Admittedly, we have to be a little bit careful with the FFI libs
I'm less concerned about the ffi libs because: 1) As a user, I only _have_ to use the low level ffi libraries: Addr, Word, Int64, ForeignObj, etc. Its nice if the high level libraries are useful too but not essential. 2) As an ffi implementer/maintainer, I only have to implement the agreed ffi interface and all the libraries on top will "just work". 3) They're not supposed to be standard so it's ok to experiment with the design a bit. 4) I don't have any code that uses them. -- Alastair Reid ps I tried to find a copy of the ffi spec on haskell.org today. After some searching, the only version I could find was more than a year old. I have a note somewhere of where the up-to-date copy is held but if anyone were to go looking for it themselves, they might have a hard time. It'd be good to sprinkle haskell.org with a few pointers to the current spec before Wednesday (which is when Hugs 2001 (including my ffi implementation) will be released.