Generating Function Prototypes

[Simon Marlow]

> > Similarly, whether there is a prototype in scope or not
> > should not affect the semantics of the call.  The FFI spec doesn't
> > say this explicitly, but I don't think it needs to.
> 
> Yes If that is the intention, then it should say so explicitly.
> And if that is not the intention then it should say that.
> 
> What I believe I'm hearing from Manuel is that the presence of
> function prototypes is allowed to affect code generation.  This is
> what ghc -fvia-C does but (by implication) not what GHC's native code
> generator does.  Even within a single compiler we find both
> interpretations of the ffi spec...

It can't be the case that prototypes affect the semantics, because it would be impossible to implement in a compiler that doesn't compile via C and doesn't understand C header files.  Well, I suppose the compiler could compile wrappers with calls to the external functions using a separate C compiler... but I think the intention is that the calls should be compilable by a standalone Haskell compiler regardless of the compilation route.

The fact that the existence of prototypes might affect the code generated under GHC with -fvia-C could be considered a bug, which is why we turn on the appropriate warnings from the C compiler and strongly recommend that people use prototypes and header files when compiling via C.  There is still the possibility that the prototype can affect the calling convention when the prototype doesn't match the Haskell type, but I *think* you'll always get a warning in that case.  Anyway, I still consider this an implementation issue.

I guess the spec should clarify this point.

> As someone who wants to be able to write portable ffi code (actually,
> I want to be able to steal ffi code originally written for GHC :-), I
> need to know what ffi code is portable and what is not.  I have
> attempted to describe what is currently portable between the different
> implementations.  I believe it is the job of the ffi to be clear about
> what it can guarantee and what it cannot.

To write portable code, personally I wouldn't ever use header file annotations in FFI declarations.  Some implementations might require you to specify appropriate header files using a compiler-specific mechanism in order to generate correct code, but that's no worse than having to specify the right libraries from a portability point of view.

> > I must have lost track of the discussion because I can't remember at
> > which point someone said that the Haskell type does not completely
> > specify the calling convention.
> 
> If specifying a header file with a function prototype is allowed to
> affect the generated code (i.e., the calling convention), then it is
> clear that the Haskell type does not completely determine the calling
> convention. 

I claim that it is not.  The FFI spec might need to clarify this issue though.

> And if it does not, let's remove header files from the spec.

I won't comment on that one...

Cheers,
	Simon