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
SimonM:
We had a long discussiong about this a while back (sorry for sounding like a broken record!),
The questions that come up as I implement the ffi are mostly things that are not clear from the spec. This is a particularily good example of that - there's no example and the explanation is brief and open to many interpretations. I could hunt through the archives and guess at what the final decision was or I could ask for clarification so that we all agree on what change is needed to the report (or I look foolish when the appropriate section of the report is pointed out to me). In this case, all I could find was a brief discussion with no final conclusion. (Or maybe I missed the conclusion - the subject lines one the messages are fairly uninformative so I skimmed old mail fairly quickly.)
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 more I look at it, the more I agree with you.
From the discussion, it seems that the purpose is to support .net. But I don't understand why .net concerns affect the ccall calling convention instead of the dotnet convention?
Portability seems to be a major problem - even if we restrict ourselves to Unix systems, there's no sense in being able to specify libX11.so unless you can also specify the directory. Which directory will that be? Well, it varies from one system to another. Can someone come to the defence of the lib specifications because, at the moment, I see no argument for keeping them in the spec. The only thing they might be useful for is that often an ffi module needs a little file of support code and it's convenient to have a way of mentioning that file. (btw This isn't me trying to get out of implementation work: Hugs now supports the lib specifications and, as of last night, is able to load and run the HGL examples. To achieve this, I had to fix GreenCard which had clearly not been required to generate a library spec for some time since what it generated was syntactically incorrect.)
I'd be delighted if Hugs adopted a package system similar to GHC's
I think I'd be happy if this happened too - but I think I'll leave that to someone else... In the meantime, I'm leaning towards the following interface for Hugs (GHCi and other interactive systems might provide a similar interface): hugs +G Foo.hs --lib="-L/usr/X11R6/lib -lX11 -lc" or, simpler still, hugs +G Foo.hs Bar.hs --lib="/usr/X11R6/lib/lib/X11.so.6 /usr/lib/libc.so.5" [The +G flag is a way of telling Hugs that it is to generate ffi code not to load and run code - so this is something that tends to be written at program install time not during normal runs.] Anything needing compiled as a result of loading Foo and Bar will be linked against these files. GHCi could do something similar but it would start by loading these files into the global namespace and then any dynamically loaded code or foreign imports would do lookups in these files. [Actually, Hugs probably would not use --lib= because Hugs traditionally uses cryptic, confusing flag names...] -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
participants (2)
-
Alastair Reid -
Simon Marlow