[Added Malcolm to list to be sure he gets this] With the GHC folk saying they ignore lib specs, the NHC docs saying they ignore lib specs (first bullet in http://www.cs.york.ac.uk/fp/nhc98/ffi.html) and Hugs currently treating the lib-spec as arguments to be added to the CC command line but keen to change to something sane, I propose that we drop lib specs from the ccall part of the ffi specification. This will eliminate a potential source of non-portability and will avoid the issue of global vs. local namespaces that I raised the other day. (Namespaces aren't an issue because, with no way of specifying which namespace a foreign import comes from, it can only come from the global namespace.) How the libspec is specified is outwith the scope of the report but it's worth describing to be sure that all implementations present and future have a viable way of implementing it. The way Hugs' ffi works is that you run Hugs in generate mode to produce a .so file containing the wrappers for invoking C functions, then you quit and you run Hugs in normal mode. What I propose to do for Hugs (might be useful for GHCi too?) is that when you run Hugs in 'generate ffi mode' (i.e., specify the +G flag) you can also specify a list of .{o,a,so,obj,dll} files which are alleged to contain relevant definitions. These will be stored in the file generated by Hugs. When you run Hugs in normal mode and it loads a prebuilt .o file, it will also dlopen any .{o,a,so,obj,dll} files mentioned in the .o file. (There's a slight circularity there - you really ought to load the extra files _before_ you load the Hugs-generated files that refers to them. This may require addition of an extra file - I'll need to see.) No doubt GHC and NHC will continue to use package descriptions. (Hugs won't use them because... packages haven't been implemented for Hugs yet.) I'm not sure what GHCi's ffi story is at the moment. Do you have to compile ffi files with GHC and then load them or does GHCi still do on-the-fly marshalling? If the latter, GHCi will need to get lists of libraries from somewhere: command line/environment variables, package descriptions, or some other file. -- Alastair Reid Simon Marlow <simonmar@microsoft.com> writes:

Ok, I can't see the conclusion either, but I seem to recall that at one stage the library specs were removed from the spec altogether and only came back again because of .NET (no, I'm not sure why they're in the C section of the FFI spec either).

From the GHC perspective they're not useful, and it would be headache to implement them if we had to. Fortunately the current spec says that they are a "hint" only, so we don't have to implement them. But that causes problems for anyone wanting to write portable FFI code: by definition, because the interpretation of the lib spec is implementation dependent, it can't be used in portable code. So really, I think it should be removed.

If the FFI spec says anything about libraries, IMHO it should say that the methods used to find and link against external libraries are implementation dependent. We as implementers can always get together and agree on a common mechanism (packages, command-line arguments, whatever) to make life easier for the punters.

Alastair:

...

ps In case it wasn't clear yesterday, I think the spec should be clear about whether C libraries live in local or global namespaces. I propose that they should be in a single global namespace. This will require no change to GHC but will require a change to Hugs' historical behaviour.

Simon:

Fine by me.

"Simon Marlow" <simonmar@microsoft.com> 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 specs were removed from the spec altogether and only came back again because of .NET

Correct.

(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). Cheers, Manuel