[C2hs] Re: patch to c2hs to support asm constructs

[Manuel M T Chakravarty]

Duncan Coutts:
> On Fri, 2005-07-29 at 01:39 +0100, Duncan Coutts wrote:
> > Hi Manuel,
> > 
> > Attached is a darcs patch to c2hs to add support to the lexer and parser
> > for asm statements and annotations. It also adds support for the string
> > literal concatenation feature of C.
> 
> Sorry I messed up the patch slightly and missed a bit out. Attached is
> the correct patch.
> 
> Note that this is a replacement patch, it's not cumulative.

Thanks!  Your patch is in the public repo now.

> BTW, we've still got another patch that's we probably need before we can
> use the mainline c2hs again. However I don't understand it! I'll have to
> get Axel to look into that one. :-) It's something in the GenBind
> module. As I recall it was something to do with foreign pointers.

How big is the change?

> I was experimenting with using your mainline c2hs to build Gtk2Hs. It
> generates lots of little .h files and uses them in the foriegn import
> declerations. The behaviour of our c2hs fork (at least when using the
> precompiled headers feature) was not to mention any .h file in the
> foreign import decleration. That way we only have to mention the .h
> files that we pass to c2hs in the ghc package files and more importantly
> we do not need to distribute all the .h files. Indeed these .h files are
> always trivial, they just #include the main .h file we passed to c2hs in
> the frist place. So is there a way to avoid generating the .h files if
> they are trivial?

Not including any .h in foreign imports is not a portable way of using
the FFI.  The only feasible "optimisation" for c2hs seems to be that if
it generates a "foo.h" with only

  #include "lib.h"

then it could drop "foo.h" and put "lib.h" into the foreign import
declaration.  That'd be a reasonable, generally useful feature, which
I'd be happy to include.  I'd prefer not applying this "optimisation" by
default, though, but only when requested via a command line option.
That is as some people may rely on the .h generated by c2hs in their
packages.

Is that a reasonable compromise?

> I note that with c2hs now using cabal that it requires at least ghc 6.2.
> In that case would patches that depend on library updates that come with
> ghc 6.2 be ok? I'm thinking of the finite map libraries since the ghc
> ones are rather faster. I recall there being a measurable speedup when I
> switched them in the Gtk2Hs fork of c2hs.

I am happy to rely on anything that is in the hierarchical libraries of
GHC 6.2 *and* of nhc98 and Hugs.  I'd like to keep the code base
portable.  AFAIK, Data.Map is portable.

Thanks again for the patch,
Manuel