> 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 _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi