Manuel M T Chakravarty
chak at cse.unsw.edu.au
Mon Aug 12 21:46:13 EDT 2002
Alastair Reid <alastair at reid-consulting-uk.ltd.uk> wrote,
> > Under .NET each DLL has its own namespace, so the [lib] spec is
> > needed to disambiguate. Since it's a namespace issue, I'd feel
> > better if on .NET the name of the C function took a different form
> > (perhaps <lib>.<function>) and [lib] is removed from the spec.
> Isn't that just a different syntax for the same thing?
> The thing I don't understand here is why .net issues affect the ccall
> calling convention and not the dotnet calling convention?
> I'm totally happy with defining dotnet to be ccall plus [lib] (or
> lib.) specifications (much as stdcall is defined as a small delta on
> ccall). I know what that means and it is implementable on platforms
> which support dotnet. It is trying to make C fit into the .net scheme
> of things which causes problems.
.NET is a different beast from other calling conventions in
that you may want to compile Haskell ccalls to .NET
intermediate language. In other words, it is about being
able to implement ccall *on* .NET. Thus, the mix.
At the moment, there doesn't seem to be much support for
[lib]. The last message from SimonPJ (a while ago) on this
issues also seems to indicate that he isn't to bothered
about it. But AFAIK he is away at the moment.
So, unless SPJ strongly objects when he returns, let's go
with Alastair's change.
More information about the FFI