Re: hsffig issues (was: Suggestions for #defines with FFI)

On Thu, Jul 28, 2005 at 12:08:11AM -0400, Dimitry Golubovsky wrote:
> >1) It didn't declare types for the imported constants, so Haddock
> >wouldn't generate a list over it.
> 
> I never tried to make hsffig output documentable: the whole idea is just 
> to write "import FOO_H" in Haskell as one would write "#include <foo.h>" 
> in C.

Yeah, I understand.  I'm just trying to push it a bit 

I'd rather be able to directly re-export all that again, saving me
having to key it all in manually.  Or perhaps declare my own transformer
over it (a plugin of sorts, perhaps, so I could work nicely with
enums-from-macros in the scenario I've described)

> I mentioned this in the Tutorial: hsffig gives the Haskell compiler the 
> same look at information about the library to import as the C compiler 
> would have. It is hard to separate such things: your header file that 
> you include may include ten other headers, five of them related to the 
> library, and the rest from /usr/include

I think, though, that it shouldn't be too hard to filter the data coming
back from gcc.  For instance, you could just look for stuff after a line
ilke:

# 1 "/usr/include/ldap.h"

and start ignoring when you see a reference to any other file.

> >3) It tried to list some of the GCC internal conditionals as constants,
> >making the .hsc not compile unless I manually removed some of them.
> 
> Can you provide an example of that? With (almost antique) egcs-2.91.66 I 
> never had anything like this. What was in the .hsc file and what was the 
> compilation error?

Without posting too many hundreds of K on a public mailing list, the
output of gcc -E -dD /usr/include/ldap.h begins like this:

# 1 "/usr/include/ldap.h"
# 1 "<built-in>"
#define __STDC_HOSTED__ 1
# 1 "<built-in>"
#define __GNUC__ 4
# 1 "<built-in>"
#define __GNUC_MINOR__ 0
# 1 "<built-in>"
#define __GNUC_PATCHLEVEL__ 1
# 1 "<built-in>"
#define __SIZE_TYPE__ long unsigned int
# 1 "<built-in>"

The problem in this particular case was, if memory serves,
__STDC_HOSTED__.  hsc2hs was unable to evaluate that macro.

> >I really like the idea, though.  Autodetecting these is great, since
> >they could vary somewhat from implementation to implementation.
> 
> Exactly: the Haskell compiler gets the same information (e. g. from 
> features.h) as the C compiler got when compiling the library.

Well, that sort of stuff I can already get with hsc2hs (#type and all
that).

What I was really speaking about is that there is a standard for the
LDAP C API.  There are many implementations of it, and there are some
optional parts of the API as well as some vendor-specific extensions.
With a slightly smarter hsffig, it seems it would be possible to provide
the exact features in Haskell that are exposed to C for any given
implementation, automatically.  Really Cool (TM) in my book.

Thanks for all your great work.  BTW, I have packaged hsffig up for
Debian and will be uploading it as soon as possible.

(Someone on #haskell had actually pointed me to it, and I had tried it
out, before I started this thread.)

-- John