FFI Report, CVS Id 1.5

Sven Panne Sven_Panne at BetaResearch.de
Tue Jun 12 05:00:09 EDT 2001


Marcin wrote:
> Being just Storable is not enough to generate a foreign call.

Exactly.

> For example floating point arguments might be passed in different
> registers than integer arguments. [...]

... or 'long long's being passed in a register pair, starting at an even
register number. :-P  (happens on PowerPC g++)

I think it boils down to the following: For every calling convention there
is a fixed set of primitive types which the Haskell system must know about,
e.g. CInt, CFloat, Ptr a, ... for ccall/stdcall. The only convenience which
can be offered for the programmer are opaque newtypes around these types or
automatic flattening of pure product types (like e.g. GreenCard does for
tuples IIRC). Marshaling and parameter passing are two different things.

In a nutshell: Nice at it seems, the Storable-idea has to be replaced by
something else, I fear.

> >     foreign import "static foo" foo :: t
> >     foreign import "static"     foo :: t
> >     foreign import ""           foo :: t
> > 
> >   Is the last one nice?
> 
> Not nice and not necessary if the whole "" can be omitted, but it
> makes rules more consistent. In particular this should be legal:
>     foreign import "&" foo :: Ptr t
> so with "static" too...

I'm with Marcin here.

> (I still think that the "static" keyword is not necessary.)

How would you import a function named "static" then?

> > I have added a restriction: exported variables must be
> > defined by a function or pattern binding in the *same*
> > module.
> > 
> > This shouldn't be a serious restriction in practice, but
> > may make live easier for some systems.
> 
> Why? The implementation could always generate a wrapper.
> 
> And it is possible to do a non-FFI export of entities defined in
> other modules (even written qualified), so FFI exporting rules could
> be consistent with it.

Again, I'm with Marcin. This restriction looks very artificial and ugly.

Cheers,
   S.

P.S.: Regarding the funny restriction on the type of f.i.d.: This has
in effect been removed & fixed in GHC's implementation.
-- 
Sven Panne    Fon: +49/89/99567000    Fax: +49/89/99567461
BetaResearch GmbH,    Betastr. 1,    D-85774 Unterfoehring
mailto:Sven_Panne at BetaResearch.de    http://www.betaresearch.de




More information about the FFI mailing list