Using c2hs to generate bindings

[Kleidukos]

On the advice of @divarvel and after discussing with @angerman, I would like to explore the idea of using c2hs for the generation of bindings, with the important distinction that we ship the generated Haskell code in the sdist when uploading the package, as not to impose any burden on the downstream users at build-time.

cc @kozross & @jmcardon

[kozross]

I think this is sensible. c2hs isn't particularly unfamiliar, and shipping the generated code shouldn't pose problems I don't think.

[jmcardon]

I'm not too opinionated about this, but It might make sense to simply use unsafe foreign calls for a few functions. I'm not so sure, almost all of them manipulate an out pointer and I'm not sure whether it's sensible to keep it in IO and run it with unsafeDupablePerformIO later downstream (e.g as is the case in hashes) or simply expose as an unsafe foreign call.

Not for all functions in particular though. For example, streaming-style hashing (crypto_generichash_* family of functions for streaming hashing) likely makes a lot more sense to use in IO.

[kozross]

You definitely want to stay in IO for close bindings. There's a lot of out-parameter usage, and this only makes sense in a mutable context. For FFI, the only mutable context we have is IO, since ST isn't possible. If we provide a high-level wrapper, we can make the decision to run in ST, or wrap some other way: this decision should not be made at the binding level.

[jmcardon]

👍

[angerman]

Just make sure to use CApiFFI

[Kleidukos]

Yup', this goes in the coding style guide. :)