No subject

phrase "foreign export" in front of the normal type
signature of a function (as opposed to in addition to that
type signature).  I never had this in mind and it has always
been different in GHC and in Sigbjorn's FFI spec.  In fact,
being able to have

  foo :: Num a => a -> a
  foo  = ...

  foreign export foo :: Int -> Int

was always sold as a feature of the system.

Further additions to the FFI
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IMHO, the FFI should really be self-contained and not rely
on other non-standardised extensions/libraries.  Therefore,
I propose some additions.

* I think, we should include the `Bits' module (or something
  similar).  It is needed, eg, to handle bindings to C
  functions that expect bit vectors as arguments.  

* To implement marshalling for foreign imported pure
  functions, `unsafePerformIO' is essential.  We could add
  it to the module `Foreign' or `MarshalUtils'.  This raises
  the question of whether `unsafeInterleaveIO' falls in the
  same category.  I think, we should add `unsafePerformIO'
  and leave `unsafeInterleaveIO' our as it is less important
  for the FFI.

* Why do we only have `Eq' on ForeignPtr, but also `Ord' and
  `Show' on Ptr?  I'll add `Ord' and `Show' to `ForeignPtr'
  unless their are objections.

* Should HsFFI.h include a function like GHC's
  startupHaskell()?  For linking Haskell libraries into
  foreign code that seems to be necessary.  So, I vote for
  inclusion. 

Superflous stuff
~~~~~~~~~~~~~~~~
* I am still not convinced that we need
  `Storable.destruct'.  For deallocating special purpose
  structures that need a deep traversal, shouldn't we just
  use a custom function?

* I am also not really convinced about
  `MarshalUtils.withMany'.  There may be situations, where
  such a function is handy, but should it really be in the
  standard libraries?  Moreover, it isn't really marshalling
  specific - it is JAFL (Just Another Function on Lists).

Names
~~~~~
* I don't think `CTypesISO' is a good name.  Maybe
  `CTypesLib' as it contains the types from the C library
  (as opposed to the normal builtin types)?  Or put it all
  into `CTypes' after all - that doesn't mean GHC (or any
  other compiler) has to put it into a single module, just
  for the definition.  I tend to having one module only.

PtrDiff
~~~~~~~
Maybe after all, `PtrDiff' wasn't that bad an idea.  To
assume that a pointer difference fits into an `Int' (what we
do at the moment) is pretty dodgy.  Remember that all that
H98 requires of an `Int' is that it has >=30 bits.  IMHO,
this is pretty weak for a general representation of a
pointer difference.

The annoying thing about our old use of `PtrDiff' was that
it made `plusPtr' a pain to use (as we had to cast the
offset to a `PtrDiff' first).  A simple solution would be

  plusPtr :: Integral i => Ptr a -> i -> Ptr b

I am actually pretty convinced that this is the right way to
go.

Argument types for foreign functions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As you can see, I have removed my construction for using
`Storable' to specify the types that can be used as
arguments to foreign functions.  However, I don't agree with
the posts claiming that this route would be unworkable.
Whenever a type `T' is `Storable', it can be passed to a
foreign function in one of two ways:

(1) The compiler has special knowledge about the type and
    just generates the normal (possibly type-dependent)
    argument passing code.

(2) If the compiler has no special knowledge about the type,
    it `alloca's temporary storage for the type and `poke's
    the argument into that location.  Then, it generates a
    stub routine in the foreign language that gets a pointer
    to the temorary storage instead of the actual argument.
    The stub routine extracts the argument and calls the
    actual foreign routine.

The idea is of course that the compiler (at least if it
aspires to generate decent code) has special knowlegde about
all the standard types.  So, (2) is only the fallback for
weird user-defined instances of `Storable'.

(+) I like this approach, because it makes the FFI
    definition nicer.

(-) Unfortunately, it is more fuss for the implementation
    and probably doesn't make a big difference in practice.

I have removed it from the report, because "worse is better"[1]
(at least that's what some people claim; although it is
somewhat against the spirit of Haskell, which tends to put
elegance over simplicity of implementation).

[1] http://www.jwz.org/doc/worse-is-better.html