[ Re: FFI in nhc98 - followups set to ffi@haskell.org ]
Int/Word 8/16/64 are not really supported properly at all right now.
With QForeign they work well enough that the Curses interface works. QForeign provides Num/Integral/etc. instances, and Int64/Word64 are not used much.
Yesterday, I commited lots of code for Int/Word 8/16/32/64. Some work is still required for 64-bit value conversions only.
I miss foreign export dynamic the most.
This is the trickiest part to implement, of course. As far as I know, we can lift the most difficult sections directly out of Hugs or ghc's implementation and re-use it. (But see further comment about foreign import dynamic below.)
Then the fact that case does not work for arbitrary numeric types.
I don't understand - can you explain? Surely the Num instances for Word/Int 8/16/32/64 mean that a literal integer 3 in the source code becomes (fromInteger 3) in reality, and this should be fine in case comparisons.
Then foreign label and foreign import dynamic.
Foreign label is probably not too difficult to get going quickly. As to dynamic import and export, I have never had any luck playing with dynamic loading of libraries in C. Can anyone recommend a good tutorial? The manual pages I have read so far were not very enlightening. I'm afraid that, until I understand how to get dynamic libraries going in C, there will be no provision for them in nhc98.
addForeignPtrFinalizer is not emulated under nhc because it does not provide addForeignFinalizer :: ForeignObj -> IO () -> IO () (this function is not so important).
Specifying a finalizer as IO () (i.e. as Haskell code rather than C code) is not a straightforward idea at all. Currently in nhc98, such finalizers are recorded, but may never be run. This will be fixed eventually. However, as far as I am aware, we agreed to remove the idea of *multiple* finalizers from the common FFI spec, because they have too many potential semantic problems.
QForeign comes with part-of-Parsec and GetOpt from ghc, which are needed by it but not distributed with nhc.
The next release of nhc98 will include GetOpt, Parsec, and a whole host of other libraries.
It also emulates ghc's Bits module with Bits class; nhc's Bit is different.
Yes, nhc98's Bit library follows version 1.3 of the Haskell Library Report, whereas ghc's Bits library has never been standard. :-) Fortunately, the next release of nhc98 can provide both interfaces if you wish.
nhc does not provide CTypes and CTypesISO modules, nor HsFFI.h
CTypes and HsFFI.h exist as of yesterday. CTypesISO will follow shortly.
8-bit Chars cause my Curses interface to use ASCII substitutes for semigraphics. In Unicode-enabled Haskell implementations (i.e. development versions of ghc) it represents semigraphics as appropriate Unicode characters,
Haskell characters are represented internal to nhc98 as 32-bit values, and always have been. I don't think Unicode should be a particular problem, although as you point out, we don't yet have a library for conversions of char-encodings between 8-bit ASCII, UTF-8, UTF-16, and UTF-32.
[ hmake ] What I want to say is that sources of these files are in different directories, and their *.o and *.hi files don't exist yet, but they will be in the directory where the sources reside.
Is it possible to let hmake generate dependencies with that assumption? Or could hmake be changed to support such scheme?
Yes, it is possible. I've just committed a small patch to CVS which does what you want. Regards, Malcolm