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