On Tue, 2006-04-25 at 10:16 +0100, Simon Marlow wrote:
On 25 April 2006 09:51, John Meacham wrote:
On Tue, Apr 25, 2006 at 09:40:58AM +0100, Simon Marlow wrote:
Admittedly I haven't tried this route (not including *any* external headers at all when compiling .hc files). It might be possible, but you lose the safety net of compiler-checked calls.
yeah, perhaps a hybrid approach of some sort, when building the package, use the system headers, but then include generated prototypes inside the package-file and don't propagate #includes once the package is built.
or just an intitial conformance check against the system headers somehow (?), but then only use your own generated ones when actually compiling haskell code. It would be nice to never need to include external headers in .hc files.
Hmm, the more I think about it, the more I like this idea. It means we could essentially forget about the public/private header file stuff, we don't need the extra pragmas, and there would be no restrictions on inlining of foreign calls.
That would be nice. If the module that imports the C functions were compiled via-C with the headers (or some other check like c2hs does) then we'd get the safety check. Then other client modules could be compiled without a prototype at all (or one generated by the Haskell compiler). As you say, it is a bit of a pain that users of Haskell bindings libs need to install the development versions of C libraries. For example Gtk2Hs users on windows need the full dev version of Gtk+ which is considerably larger than the runtime version. One downside would be that we would only be able to call C functions which conform to the standard platform ABI. As it is at the moment (perhaps somewhat by accident) we can call C functions that have non-standard ABI annotations in their prototype, eg: int foo (int) __attribute__((regparam(3))) ok that's a silly example, bu there are more sensible examples of ABI weirdness - especially on arches like mips which seem to support half a dozen different ABIs. Perhaps we don't care, I'm not sure I do. Duncan