(no, I'm not sure why they're in the C section of the FFI spec either).
Because they are for implementing calls to C code in Haskell that is compiled to .NET ILX.
This doesn't mean that I want to necessarily defend them, but this was the reason for their inclusion. Essentially, SimonPJ was saying that to compile Haskell including "foreign import ccall"s to .NET ILX, we need the library spec.
I am not too fussed about .NET, so don't mind if we nuke the [lib] specs (as Alastair already did in the CVS version of the spec).
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. BTW I didn't know the spec was in CVS somewhere... where exactly? Cheers, Simon
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.
BTW I didn't know the spec was in CVS somewhere... where exactly?
haskell-report/ffi (and don't forget the grammar.sty file I pointed at in the commit message) -- Alastair
Alastair Reid <alastair@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. Cheers, Manuel
participants (3)
-
Alastair Reid -
Manuel M T Chakravarty -
Simon Marlow