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. So let's simply make callconv mandatory, "ccall" isn't that long after all.
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. But this should be made clear from the FFI spec. Cheers, Sven -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de
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.
That's what I think, too. In addition, I can't see that it would buy us anything.
So let's simply make callconv mandatory, "ccall" isn't that long after all.
If this is generally preferred, ok. (I won't change it, though, unless I hear more people asking for it.)
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. Alternative wordings are welcome. Manuel
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.
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. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
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
On 31-May-2001, Manuel M. T. Chakravarty <chak@cse.unsw.edu.au> wrote:
Fergus Henderson <fjh@cs.mu.oz.au> wrote,
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?
I would be fine to say that some other name, e.g. `c', means that. But `ccall' already has an existing meaning, and it would be terribly confusing if e.g. MSVC and GNU C used `ccall' to mean one thing, while Haskell used it to mean something different.
(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.)
"The ``corresponding'' C implementation is implementation-defined." Or in more verbose but probably clearer words: "The Haskell implementation must document which C implementation the `c' calling convention corresponds to."
It would be nicer to make this explicit in the grammar.
By having
callconv -> ccall | stdcall | cplusplus | jvm | dotnet | | <implementation-specific conventions>
?
Exactly. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Fergus Henderson <fjh@cs.mu.oz.au> wrote,
On 31-May-2001, Manuel M. T. Chakravarty <chak@cse.unsw.edu.au> wrote:
Fergus Henderson <fjh@cs.mu.oz.au> wrote,
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?
I would be fine to say that some other name, e.g. `c', means that. But `ccall' already has an existing meaning, and it would be terribly confusing if e.g. MSVC and GNU C used `ccall' to mean one thing, while Haskell used it to mean something different.
Are you sure that ccall has a fixed meaning outside of the Haskell community? A google search for `ccall' comes (wrt to programming languages) mainly up with Haskell references. If `ccall' is really fixed, then I would prefer to introduce a new calling convention (eg, `c') rather than using an unspecified calling convention. Cheers, Manuel
On 01-Jun-2001, Manuel M. T. Chakravarty <chak@cse.unsw.edu.au> wrote:
Fergus Henderson <fjh@cs.mu.oz.au> wrote,
I would be fine to say that some other name, e.g. `c', means that. But `ccall' already has an existing meaning, and it would be terribly confusing if e.g. MSVC and GNU C used `ccall' to mean one thing, while Haskell used it to mean something different.
Are you sure that ccall has a fixed meaning outside of the Haskell community?
Oh, sorry, I was mistaken. The name that MSVC and the Windows versions of GNU C use is `cdecl'. Using `ccall' for Haskell should be fine. Sorry for the confusion. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
participants (3)
-
Fergus Henderson -
Manuel M. T. Chakravarty -
Sven Panne