Simon Peyton-Jones [EMAIL PROTECTED] wrote,
| .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.
I think that
(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,
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
Alastair Reid [EMAIL PROTECTED] 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
Simon Marlow [EMAIL PROTECTED] wrote,
I see a lot of discussion about header files.
I see a small amount of discussion of libraries with many conflicting
suggestions.
I see no _conclusion_.
Ok, I can't see the conclusion either, but I seem to recall that at one
stage the library
