As far as functionality goes, I think, the simplest approach would be to use the language-c-quote parser inside language-c — i.e., parse with language-c-quote, and then, convert the language-c-quote AST to the language-c AST. This is as language-c contains quite a bit of functionality to analyse the C AST and c2hs needs that functionality. Rewriting it all in terms of the language-c-quote AST (which is quite different) would be a lot of (and pretty boring) work. Writing an AST to AST conversion should be quite straight forward and much less work. Concerning performance, I assume that the main difference is that language-c uses ’ByteString’s whereas language-c-quote uses ’String’s for parsing. Using ’ByteString’ in language-c-quote would be a good move anyway and shouldn’t be much work. (It’s also something, I might be able to help with.) Manuel Geoffrey Mainland :

I'm interested in merging language-c and language-c-quote, but I don't really have time to work on it at the moment. The two issues are performance and functionality; it is not clear to me what would need to be added to language-c-quote to make it as functional as language-c, and I don't know how much worse language-c-quote performs. Regardless, I think the chances of making language-c-quote API compatible with language-c are approximately nil.

Geoff

On 02/14/2014 03:27 AM, Ian Ross wrote:

...

Benedikt Huber is maintaining language-c -- he's pushed minor changes to the darcs repo recently, so I'm guessing he could also make a new release. I'd be happy to take over maintainership of language-c (I'm doing some things to c2hs and language-c is one of the main dependencies of that), though on the understanding that it would just be for minor maintenance tasks.

There is a broader question about language-c (https://github.com/haskell/c2hs/issues/57#issuecomment-27450437): there have been various requests to support the most recent C standard as well as C99, which would be a big job, but Geoffrey Mainland has another package (http://hackage.haskell.org/package/language-c-quote) that supports the latest standards, although with less analysis than language-c and probably less extensively tested than language-c (just because it's newer). Manuel has suggested that merging the two efforts would be a good idea. I don't know how keen Geoffrey would be on that, I don't know how much work it would be, and I don't know how much work it would be to update the reverse dependencies of the two existing packages (language-c has 13, language-c-quote has 2) to use a new merged package.

If we could get some agreement on a way forward, I'd be open to working on producing a merged language-c and updating c2hs to use the new merged version as a test case. (Of course, I don't want to do this in a way that results in a third C language package that needs to be supported!)

Cheers,

Ian.

On 14 February 2014 09:10, Carter Schonwald mailto:carter.schonwald@gmail.com> wrote:

Hey all, someone needs to help take over language C maintainer ship, because its going to be broken on 7.8 unless someone pushes a sdist'd with a new happy/ alex to hackage (see https://github.com/haskell/c2hs/issues/64 for an example issue)

I know Anthony and Jason have at points patched language-c for their respective needs, so i'm cc'ing em :)

-Carter

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Ian Ross Tel: +43(0)6804451378 ian@skybluetrades.net mailto:ian@skybluetrades.net www.skybluetrades.net http://www.skybluetrades.net

That's right, cabal "caches" alex/happy output in the tarball, so that users who build the package don't need to have alex/happy installed. Check yourself: % curl http://hackage.haskell.org/package/language-c-0.4.2/language-c-0.4.2.tar.gz | tar tzf - | grep dist So all maintainers of packages that use happy and/or alex have to reupload the package with a version sdist'ed on a system with the latest alex/happy to make it buildable with GHC 7.8. Roman * Daniil Frumin [2014-02-14 17:02:57+0400]

...

turns out that when the maintainer person does sdist, happy / alex are run locally by cabal somehow

Wow, how is that even possible? Where does it get alex/happy from? :O

On Fri, Feb 14, 2014 at 12:10 PM, Carter Schonwald wrote:

...

Hey all, someone needs to help take over language C maintainer ship, because its going to be broken on 7.8 unless someone pushes a sdist'd with a new happy/ alex to hackage (see https://github.com/haskell/c2hs/issues/64 for an example issue)

I know Anthony and Jason have at points patched language-c for their respective needs, so i'm cc'ing em :)

-Carter

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Sincerely yours, -- Daniil _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Fri, Feb 14, 2014 at 8:59 AM, Daniil Frumin wrote:

But the users still need to have alex and happy libraries installed, do not they?

They somewhat infamously do not have libraries. (Infamously because this means nothing registered with ghc-pkg, so cabal can't tell if they're installed or not.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Feb 14, 2014 8:38 AM, "Anthony Cowley" wrote:

On Friday, February 14, 2014, Carter Schonwald

...

Hey all, someone needs to help take over language C maintainer ship, because its

going to be broken on 7.8 unless someone pushes a sdist'd with a new happy/ alex to hackage (see https://github.com/haskell/c2hs/issues/64 for an example issue)

...

I know Anthony and Jason have at points patched language-c for their

respective needs, so i'm cc'ing em :)

...

-Carter

To clarify the situation for anyone who wants to take up the language-c mantle, I have a fork at https://github.com/acowley/language-c that lets one use c2hs on OS X Mavericks, in particular for OpenCL and OpenGL. You will probably find evidence of me reporting and talking about this issue in various places; I never got any response from anyone, but sensed a healthy amount of Won't Fix in the air.

A more popular fix has been to #define hacks for individual package build systems, but this is crazy as it means the hack has to be replicated everywhere. If c2hs is absolutely necessary, then its use of language-c should be reconsidered. All I did was hack the language-c parser to be more

wrote: liberal in the attributes it accepts. I have no reason to believe that my changes are correct, but it is apparent that nobody is using these parse results: we just need the parser to not error out.

TL;DR: Long term, language-c should have a stripped down mode of

operation that better fits c2hs's needs. Short term, my language-c fork seems to work on OS X, but I haven't tested much elsewhere. Another option is language-objective-c, which started as a fork of language-c, supports nearly everything language-c does, and I'm still actively maintaining it. Unfortunately I don't have the resources to test it on newer osx versions, so I'd appreciate if somebody else could give it a try (I'll need to push a new version for 7.8 though). John L

Manuel, Yes I am aware of that. But iirc there was some functionality I wanted that was not in language-c-quote (probably related to headers? ) But that was a while ago, so it may work now. I no longer do much work on osx though, so it's a low priority for me. Cheers, John On Feb 14, 2014 7:49 PM, "Manuel M T Chakravarty" wrote:

John,

You may be aware of this already, but I did at support for Objective-C to language-c-quote.

Manuel

John Lato :

On Feb 14, 2014 8:38 AM, "Anthony Cowley" wrote:

...

On Friday, February 14, 2014, Carter Schonwald <

...

...

Hey all, someone needs to help take over language C maintainer ship, because its

going to be broken on 7.8 unless someone pushes a sdist'd with a new happy/ alex to hackage (see https://github.com/haskell/c2hs/issues/64 for an example issue)

...

I know Anthony and Jason have at points patched language-c for their

respective needs, so i'm cc'ing em :)

...

-Carter

To clarify the situation for anyone who wants to take up the language-c mantle, I have a fork at https://github.com/acowley/language-c that lets one use c2hs on OS X Mavericks, in particular for OpenCL and OpenGL. You will probably find evidence of me reporting and talking about this issue in various places; I never got any response from anyone, but sensed a healthy amount of Won't Fix in the air.

A more popular fix has been to #define hacks for individual package build systems, but this is crazy as it means the hack has to be replicated everywhere. If c2hs is absolutely necessary, then its use of language-c should be reconsidered. All I did was hack the language-c parser to be more

carter.schonwald@gmail.com> wrote: liberal in the attributes it accepts. I have no reason to believe that my changes are correct, but it is apparent that nobody is using these parse results: we just need the parser to not error out.

...

TL;DR: Long term, language-c should have a stripped down mode of

operation that better fits c2hs's needs. Short term, my language-c fork seems to work on OS X, but I haven't tested much elsewhere.

Another option is language-objective-c, which started as a fork of language-c, supports nearly everything language-c does, and I'm still actively maintaining it. Unfortunately I don't have the resources to test it on newer osx versions, so I'd appreciate if somebody else could give it a try (I'll need to push a new version for 7.8 though).

John L _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries