Generating Function Prototypes

[Simon Marlow]

> I just reread that section and can't see anything that contradicts the
> idea that the FFI implementation ignores any header files provided.
> For example, the phrase:
> 
>   "implements calls to C functions ... as if a function prototype for
>    the called functions is in scope"
> 
> can be interpreted as meaning:
> 
> 1) Will generate code (by generating machine code directly, by
>    generating C code which is then compiled, or by some other means)
>    which assumes the existence of a prototype _even if the user does
>    not supply one_.
> 
>    [I see this as the most obvious interpretation of the phrase.]
> 
> 2) Will generate C code which #includes any header files the user has
>    provided.
> 
>    [I see this as a less likely interpretation but it seems to be the
>    one you intend?]

Neither, I think.  You're taking an operational interpretation of that
phrase, when it is really just talking about the semantics of the call.

For example: a C function which takes a float as an argument has two
possible calling conventions: the argument may be promoted to double
(used by the C compiler when no prototype is in scope), or it may be
passed as a float (used by the C compiler when there is a prototype).
The FFI spec simply says that it is the latter calling convention that
is used.

Whether a header file is supplied or not should not affect the semantics
of the call (I'm pretty sure you agree with this, but we seem to have
lost track of this central concept somewhere along the way...).
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.

> My reading of the whole section is that every mention of users
> providing header files and function prototypes refers to compiling the
> C code being called not the Haskell code doing the calling.  The
> examples of using foreign import don't show the use of header files
> though the second example needs a header file to compile correctly
> with GHC.

Only when -fvia-C is on.  This is a compiler-specific issue, the FFI
doesn't need to say anything about it.

> If the intent is that any user-provided header files must be 
> obeyed, then
> I think the spec should explicitly say:
> 
>   When a header file containing a function prototype is not provided,
>   the function calling convention employed is undefined.  It may vary
>   between different operating systems, between different 
> Haskell compilers,
>   and between different functions.

This is exactly what we *don't* want - the semantics should be specified
by the FFI declaration alone, independent of any header files.  Again,
I'm sure you agree with this - but why do you think that supplying a
header file should make a difference to the semantics?

> I attach my rewording of the section.  Note that I am trying to make
> it quite clear that an ffi declaration is not portable unless you
> provide function prototypes except in the special case that your C
> compiler generates the same code with or without a prototype.

I really don't think the FFI spec needs to say anything about this at
all.  If a particular compiler requires prototypes in order to generate
correct code (such as GHC when going via C) then this is a matter for
that compiler's documentation.  Indeed, the GHC User's Guide does
mention this.

[ Heh.  Now I remember why I didn't like being able to specify header
files in the FFI declaration :-) ]

> ps I still think we're better off removing header files completely and
> having the Haskell type completely determine the calling convention
> employed.  But since I'm not getting any takers on that, I'll 
> settle for
> pinning down the spec as tightly as possible.

Aha!

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.

Cheers,
	Simon