> I'd love to see these things well documented. I never saw this in any
> docs I've read. Actually I don't think I've seen the Hugs FFI documented
> anywhere, but I may have missed some docs.
It's documented in a C header file :-)
The new FFI that Simon Peyton-Jones referred to is described in the
"foreign function interface for Haskell" document hanging off:
http://www.dcs.gla.ac.uk/fp/software/hdirect/
[I'm not sure that this is the most recent version so you should view
it as an indication of how the FFI will look rather than the
definitive document (unless the Hugs-GHC folks tellyou otherwise.]
Hmmm, I'm starting to see what you're talking about. When we switch
from the current FFI to the new FFI, we'll break all the code that
depends on Hugs98's ffi. And then in 3 years time (say) we'll add
support for 128 bit ints (since all architectures will use them as
standard by then), remove support for 32 bit ints (ludicrously small
for real applications) and change our preferred form of weak pointer
another 3 times and, again, we'll break a bunch of code. But this
problem isn't really unique to the FFI - the language supported by
Hugs already changes from one version to another (libraries change,
various non-standard extensions change, the language standard changes,
etc). The program I'm currently working on simply will not load in
older versions of Hugs and I'm not doing any FFI stuff. Why is the
FFI different from any other part of Hugs? Or, to put it another way,
shouldn't we be talking about version control for arbitrary Haskell
files which include but are not limited to FFI-related files.
> May I ask what version changed from 1 to 2?
[My memory is a bit vague but it might have been as follows.]
GreenCard 1 used version 1. This used a slightly simpler (in the
dubious sense of involving less functions) interface to the Hugs
internals because the generated code exploited more knowledge about
Hugs innards.
GreenCard 2 used version 2. This removed direct access to data
constructors and added better support for types like pointers, foreign
objects, etc.
Alastair Reid
