Question

I maintain the augeas FFI library at http://hackage.haskell.org/package/augeas

Recently augeas added an aug_to_xml method that includes a parameter with type xmlNode from libmxl2. It looks like libxml is the FFI library for libxml2, but it hasn’t been updated in a while, and it doesn’t look to have Debian packaging, so I’m hesitant to add it as a dependency to the augeas FFI library.

So my question is when I add FFI support for this function, would it be better to add the dependency to libxml, which might lead to packaging problems later on, or would it be better to use something like a opaque type as per the FFI cookbook so there’s no interlibrary dependency ?

If I go with the opaque type approach, and the users want like to use libxml on their own, could they go about casting my type as a Text.XML.LibXML.Node ?

Answer 1

An opaque type is probably the best route here if you want to include the function, but I’d be sceptical of including a function that is only usable with unsafe coercion to another library’s type (which would be indeed possible, yes, but would rely on the internal representation of the libxml binding’s Node to not change — risky).

I would suggest simply not adding the function; if someone wants to use it, they can easily import it themselves, and if your binding is appropriately direct, it’ll probably be easy for them to use it with your binding’s types. Of course, if it’s likely to be commonly-used, you could easily bundle this up into a package by itself, though I highly doubt a package that was last updated in 2008 and doesn’t even build on GHC 6.12 onwards is going to get much use.

So, I’d just omit the function from your binding, or use an opaque type if you really do want to include it.