What are the differences between inline-c and language-c-inline?

Question

I've been briefly looking into quasi-quotation libraries for Haskell. These libraries allow Haskell to integrate with other languages. For integrating with C, there appears to be two packages with similar functionality:

• inline-c
• language-c-inline (which uses language-c-quote)

As I'm looking to build a quasi-quotation library of my own, I'm interested in design choices, API differences, performance etc.

The only difference I'm aware of is that language-c-quote supports C and Objective-C, whereas inline-c supports C.

How would you distinguish these packages? What are the fundamental differences? Are they, in fact, similar?

Answer 1

Some differences where (shortly) discussed in inline-c's reddit announcement:

How does this compare to language-c-inline?

• In inline-c we have a very simple core library which is easily extensible with additional anti quoters. I wanted the core functionality to be very predictable, and leave fancier marshalling up to specific use cases. In language-c-inline the marshalling works with a mix of hard-coded rules and user-supplied Template Haskell functions.
• We wanted to make the language to include the C code as simple as possible. The inline C is spliced with a quasi quoter and no Template Haskell functions. The inline C code specifies the Haskell variables to capture using anti-quoters, and the target types are all specified using C syntax. As I say in the blog post I cared quite a bit that this is the case, to have confidence that what you're getting in C is what you expect. Relatedly, only the anti-quoters are examined: the rest of the C code is not parsed and left verbatim, so we don't have to worry about eventual incompatibilities between the C compiler the user is using and the Haskell C parser that language-c-inline uses.

• We're also making sure that the infrastructure and build process is smooth. The addTopDecl function is used to avoid having to populate tables at runtime like language-c-inline does, and I also employ various tricks to make sure that everything will work smoothly across builds. For example, the names of the generated C functions is based on the hash of the contents of the function itself. This is quite important to guarantee that repeated builds of the same file by cabal -- for example when compiling with profiling support -- result in the same C symbols being generated, while making sure that the the symbols are the same only if the C snippets in the module are the same.

  […]

In short, the two libraries are very similar in spirit, but we coded inline-c to be better suited to our needs taking different design choices. Some of the advantages above could be easily ported to language-c-inline, especially the ones in the last point.

The announcement on fpcomplete also contains additional information, but all in all, yep, their somewhat similar.