FFI Addendum, CVS Id 1.19

[Manuel M. T. Chakravarty]

"Simon Marlow" <simonmar at microsoft.com> wrote,

> > 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.

I would prefer to leave it as it is now.  The changes so far
really have been necessary for defining some FFI bindings
properly.  The points that you raise above are perfectly
valid, but I think they are more in the fixing H98
territory, which I think, we should stay clear off.

> > * 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.

What's the planed time line for 5.04?  But I really would
like to get FFI 1.0 out without any further delays.

> 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

One more reason to decouple this from FFI 1.0.

> MarshalUtils.withMany disappear by the way?

We agreed to have it somewhere in the new libraries as it is
really a list function and not essential.

> 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.

That would be what H98 suggest, I guess.

> 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.

Ok, I took that paragraph away and made Section 2 a bit clearer.

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

I think, the API should use finalise, too.  But it's too late
now to change the API, so I changed the text.

Cheers,
Manuel