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 [EMAIL PROTECTED] http://www.cs.utah.edu/~reid/ _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
