[Haskell-cafe] hsffig and duplicate typedef declarations

[Dean Herington]

At 10:12 PM -0700 5/13/09, Don Stewart wrote:
>heringtonlacey:
>>  At 9:59 PM -0700 5/13/09, Don Stewart wrote:
>>>  heringtonlacey:
>>>>   I have a large body of C/C++ code at work that I'd like to be able
>>>>  to  access from Haskell via FFI.  Because the interface to this code
>>>>  is  broad, hsffig would seem to be ideal for the task.
>>>>
>>>>   I've run across one serious hitch, though.  The existing #include file
>>>>   graph is complicated and ends up declaring some typedefs multiple times
>>>>   (albeit in consistent ways).  While gcc (for example) rejects such
>>>>   practice, the Windows C compiler we're using accepts it. Does anyone know
>>>>   how feasible it would be to get hsffig to accept such practice as
>>>>  well?  I've started looking at the hsffig code (and discovered that
>>>>  the C
>>>>   grammar hsffig uses seems to get confused by duplicate typedefs), but
>>>>   thought I'd ask the list in parallel with my further study.
>>>
>>>  Have you looked at c2hs? (I'm not sure how familiar people are with
>>>  hsffig, but Dimitry Golubovsky can probably comment)
>>>
>>>  -- Don
>>
>>  Yes, I started this journey with c2hs.  Then I moved to hsc2hs, which 
>>  appeared to be a "standardized" version of the same approach.  But my 
>>  interface consists of hundreds (maybe thousands) of #defines, structs,
>>  typedefs, etc., so I quickly tired of the boilerplate wrapping code,
>>  modest as it is.
>
>hsc2hs is much simpler than c2hs. In particular, it processes the header
>files (unlike hsc2hs) to work out the appropriate type.

Yes, but both c2hs and hsc2hs require the (normally modest but for 
this situation burdensome) wrapping code.  hsffig would produce a 
(huge) Haskell module with all the interface components available. 
(In fact I have some concern about the module being too big.)  A big 
win for me would be the ability to write concise code to drill down 
through nested C structures returned by the foreign functions 
(without having to process each such module through c2hs or hsc2hs).

>I'd be interesting to hear how you go with hsffig (and you should
>contact the author!).

I'll let the list know how it goes, and will certainly be in touch 
with Dimitry.

Thanks.
Dean