Re: nhc98-1.{00,01} produce crashing programs



About this list Date view Thread view Subject view Author view

Malcolm Wallace (malcolm-nhc@cs.york.ac.uk)
Thu, 4 Jan 2001 14:22:52 +0000


[ 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


About this list Date view Thread view Subject view Author view