Re: nhc98-1.{00,01} produce crashing programs
[ 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
Thu, 4 Jan 2001 14:22:52 +0000, Malcolm Wallace <malcolm-nhc@cs.york.ac.uk> pisze:
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.
module Test where newtype I = I Int instance Eq I instance Show I instance Num I test:: I -> Bool test 0 = True test _ = False Fail: What? matchAltIf at 7:10
As to dynamic import and export, I have never had any luck playing with dynamic loading of libraries in C.
They have nothing to do with dynamically loaded libraries. foreign import dynamic is a plain generic "apply" operator in C: take a pointert to a function and its arguments, return the value returned by the function. foreign export dynamic is harder. It must wrap a Haskell function (closure) in a C function pointer. It is not possible to do this portably in C: function pointers are normally only pointers to elements of the finite set of (toplevel) functions. It should allocate a block of unmovable memory on the heap (perhaps using malloc), attach an equivalent of StablePtr of the function to it on a known offset (to be able to free it later using freeHaskellFunPtr), write there a constructed machine code which has this stable pointer hardcoded in its body and applies it to parameters passed from C, and return the pointer to the block as a function pointer.
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.
I don't remember what the official spec says. Perhaps addForeignPtrFinalizer should be dropped at all; I never used it. It is present in ghc so I carried it on to QForeign. Recently a bug in its implementation was fixed (which was discovered because of a change in the typechecker). Did it work at all previously? If not, I would just drop it.
The next release of nhc98 will include GetOpt, Parsec, and a whole host of other libraries.
Parsec currently uses local universal quantification in one module to simulate first-class modules. (I haven't uses that module in hsc2hs.)
Yes, nhc98's Bit library follows version 1.3 of the Haskell Library Report,
I didn't know it was standarized.
Fortunately, the next release of nhc98 can provide both interfaces if you wish.
Well, I used Bits on ghc because it is the only version it provides, so to port library wrappers in QForeign to nhc I had to port Bits as well. Some people say that Bits is ugly. I don't have an opinion how it should really look like.
nhc does not provide CTypes and CTypesISO modules, nor HsFFI.h
CTypes and HsFFI.h exist as of yesterday. CTypesISO will follow shortly.
I haven't found CTypes in CVS.
Haskell characters are represented internal to nhc98 as 32-bit values, and always have been.
(maxBound::Char) is '\255', characters are cut to 8 bits in string literals, HsChar is char, instance Storable Char use only 8 bits. But they indeed seem to work otherwise. I will try to port Curses' Unicode and perhaps my charset conversion machinery to nhc.
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.
Thank you, it works. BTW, 'make realclean' in nhc does not delete script/hmake-PRAGMA.{o,hi}. Since the bug in Addr I reported previously makes FFI unusable on the released nhc-1.00, I will not bother with supporting that version of nhc, and thus any changes in nhc will be reflected directly in QForeign without conditional support for the previous state, until a version of nhc is released. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK
On 04-Jan-2001, Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> wrote:
foreign export dynamic is harder. It must wrap a Haskell function (closure) in a C function pointer. It is not possible to do this portably in C: function pointers are normally only pointers to elements of the finite set of (toplevel) functions. It should allocate a block of unmovable memory on the heap (perhaps using malloc), attach an equivalent of StablePtr of the function to it on a known offset (to be able to free it later using freeHaskellFunPtr), write there a constructed machine code which has this stable pointer hardcoded in its body and applies it to parameters passed from C, and return the pointer to the block as a function pointer.
You forgot to flush the instruction cache. That is needed on some architectures. It also tends to be very bad for performance. On some systems that I've used (some version of DEC Ultrix, if I recall correctly), you had to be super-user to flush the instruction cache. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
participants (3)
-
Fergus Henderson -
Malcolm Wallace -
qrczak＠knm.org.pl