Again: FFI syntax

[Manuel M. T. Chakravarty]

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

> On 31-May-2001, Manuel M. T. Chakravarty <chak at cse.unsw.edu.au> wrote:
> > Fergus Henderson <fjh at 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