Again: FFI syntax

[Manuel M. T. Chakravarty]

Fergus Henderson <fjh at cs.mu.oz.au> wrote,

> On 29-May-2001, Manuel M. T. Chakravarty <chak at cse.unsw.edu.au> wrote:
> > Sven Panne <Sven_Panne at BetaResearch.de> wrote,
> > 
> > > Fergus Henderson wrote:
> > > 
> > > > The calling convention should not necessarily default to 'ccall'.
> > > > That would not be appropriate for all implementations.
> > > 
> > > Granted.
> > > 
> > > > Instead, I think the default calling convention should be
> > > > implementation-dependent.
> > > 
> > > Hmmm, this would make the semantics of the sources compiler-/interpreter-
> > > dependent, which is never a good thing. 
> 
> Making the semantics of a particular construct implementation-dependent is
> a good thing if the semantics that you want are implementation-dependent.
> Doing this allows the code to work correctly on different implementations
> without modifying the code.
> 
> That is the case here, I believe.  In particular, "ccall" is not abstract
> enough to use as a default.  The default calling convention -- the one that
> you normally want -- is "whatever the corresponding C implementation uses".
> But on x86, "ccall" means a *particular* calling convention (args passed
> on stack, caller pops, return value in EAX, etc.) which may not match
> the one that your C implementation uses.  If you have a C implementation
> which always passes args in registers, as is certainly allowed by the C
> standard, then you want to the default calling convention to be passing
> args in registers, otherwise nothing that uses the default will work.

How about saying that `ccall' means "whatever the
corresponding C implementation uses" on any platform?
(Nevertheless, the question of how the Haskell system
figures out what the C implementation uses, especially if
there are multiple C implementations with multiple
conventions is not, and cannot be handled.)

> > > > Also, implementations should be allowed to provide calling conventions
> > > > not on that list.
> > > 
> > > IIRC the intention for enumerating some calling conventions here is to
> > > make future implementations agree on the name of callconv when they
> > > implement e.g. a C++ or Java FFI, not to rule out other possibilities.
> > 
> > Exactly.
> > 
> > > But this should be made clear from the FFI spec.
> > 
> > The spec said,
> > 
> >   Generally, the set of calling conventions is open, as it
> >   is infeasible to cover all useful calling conventions in
> >   this report.
> > 
> > I have changed this now to
> > 
> >   Generally, the set of calling conventions is open, i.e.,
> >   individual implementations may elect to support additional
> >   calling conventions.
> 
> The words are clear, but IIRC they contradict the grammar.
> It would be nicer to make this explicit in the grammar.

By having

  callconv -> ccall | stdcall | cplusplus | jvm | dotnet |
	    | <implementation-specific conventions>

?

Cheers,
Manuel