FFI Addendum, CVS Id 1.19

[Simon Marlow]

> A revised version of the FFI Addendum including all issues
> of the last discussion is now available from

Look good...

> New stuff to check
> ~~~~~~~~~~~~~~~~~~
> * Section 5.10: Extended handling of IOError (slight variant
>   of SimonM's proposal)

This is fine for now.  The slight lopsidedness of the IOError design is
still bothering me though: there's no way to extract the IOErrorType
from an IOError, instead we have these clunky isXXXError things.  It
might be more consistent in the long run to add

	ioeGetType :: IOError -> IOErrorType

(to go with ioeGetFilePath, ioeGetHandle & ioeGetErrorString), and to
add instance Eq IOErrorType.  The reason I didn't suggest this initially
is because it would be hard to nhc98 to adopt this design, because it
doesn't store IOErrorTypes in IOErrors, unlike GHC.  This is a subject
for the libraries community to discuss, though.

> * Section 6: hs_init() & friends
> 
> Open points
> ~~~~~~~~~~~
> * Interaction of FFI Addendum with Libraries Addendum: I
>   propose to *not* mention anything about the new libraries
>   hierarchy now.  The Libraries Addendum will have to give a
>   mapping of old to new names for all standard modules
>   anyway.  I'd rather have the names for the FFI modules
>   in the Libraries Addendum.

Ok.  In GHC 5.04 the libraries will still be available under the names
in the FFI spec by using a compatibility package (i.e. you'll still be
able to say -package lang and get pretty much what you get now), but by
default you'll get the hierarchical names.

For the new libraries I think we'll want to move a few things around
anyhow: there are several things in the FFI libraries that don't really
belong there, but have to be there because there is no other standard
specification of their existence.  eg. the IOError stuff,
Foreign.unsafePerformIO, MarshalError.void, and did
MarshalUtils.withMany disappear by the way?

I like the hs_init() family in HsFFI.h.  It might be hard to implement
properly in GHC though, because we have to do module initialization and
there's no easy way to tell what Haskell modules are linked into the
program - hence GHC's extra argument to startupHaskell().  One (not very
attractive) possibility is to require that the program contains a module
Main which indirectly imports all the other modules in the program.

A couple of other minor things:

 - I would delete the last paragraph of section 3, it is just
   repeating what was said in section 2.

 - we should be consistent about finalize vs. finalise.  The API
   uses finalize, so the text should too.

Cheers,
	Simon