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

[Malcolm Wallace]

[ Re: FFI in nhc98 - followups set to ffi at 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