Library archives

[Simon Marlow]

> In conclusion, C is designed to use a single global namespace and
> things break if you try to change that.  Hence, I don't think the ffi
> for C can allow C libraries to export overlapping names.  I think the
> ffi spec should explicitly say that all C libraries are loaded into a
> single global namespace.  And I don't think the square bracket part
> can be treated like a Haskell qualified name.

Agreed.  

The library spec part of an FFI declaration is not indended to replace
the specification of libraries by command-line options or packages.  We
had a long discussiong about this a while back (sorry for sounding like
a broken record!), where some people argued that libraries should be
specified in the FFI declaration in the source code, and some people
(inc. me) argued that libraries should be kept out of the source code
altogether, on the grounds that they were too system-dependent and it
would be impossible to write portable code without resorting to CPP.
There were other reasons, but I can't remember them all now.

> The package system provided by GHC and NHC provides an alternate place
> where libraries could be specified.  Can someone familiar with
> packages and with Hugs comment on whether they'd be able to replace
> the ffi's library spec and would make sense for typical Hugs usage.
> And would that meet SimonPJ's need too?

I'd be delighted if Hugs adopted a package system similar to GHC's - we
even considered that possibility by including a field in the package
spec for specifying where source code for a package lives (which is
unused by GHC).  

I'd be surprised if GHC's package system couldn't be used relatively
unchanged in Hugs.  All you need to do is:
  
  - on starting Hugs, read a package config file (unfortunately I guess
    you'll need a yacc parser for that)

  - augment the search path with directories from packages specified on
    the command line (the source_dirs field of the package spec)

  - dlopen() libraries from packages (the extra_libraries field of the
    package spec).

Cheers,
	Simon