Alastair: >> 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.)
Simon: > See these threads, for example: > http://www.haskell.org/pipermail/ffi/2001-February/000212.html > http://www.haskell.org/pipermail/ffi/2001-May/000345.html 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_. The only conclusion is the ffi spec itself but it doesn't answer my questions. These are: 1) What is the form of a lib spec? A single library? Search paths? Omit/include file suffixes (.dll, .o etc.) 2) Is the library spec the only way of providing this information or can it also be supplied externally (e.g., on the compiler command line). The spec doesn't have to say what this way would be but it does have to say whether it exists and, I think, what can and cannot be overruled/added by this external spec. And if the answer to (2) is that there are other ways (which is what GHC has implemented), there's the important question of what if anything is special about lib specs, when would you use one way and not the other. That is: 3) What are library specs for? The only hints I got from the email archive are: 1) It might save one from calling dlsym on every namespace previously loaded. It is not clear that this is an issue though if you accept my argument from yesterday that to make C behave correctly (and also to keep static and dynamic linkers consistent with each other) you should use a single namespace (i.e., specify RTLD_GLOBAL when calling dlopen). 2) It is useful for .net - though I didn't hear why this was supposed to be relevant to people calling C. I'd like answers to these questions that are clear enough that we can agree on them and amend the spec to be clear. -- Alastair Reid [EMAIL PROTECTED] http://www.cs.utah.edu/~reid/ 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. _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
