Fergus Henderson <fjh@cs.mu.oz.au> wrote,
On 29-May-2001, Manuel M. T. Chakravarty <chak@cse.unsw.edu.au> wrote:
Sven Panne <Sven_Panne@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