Haskell wlroots bindings

32

There are two places of interest here:

  • Automated conversion from C headers into some intermediate general format.

    People have been trying this forever and the outcome is inevitably trying to generalize C itself. The Vulkan XML directly embeds macros, C bitfields and types like <type>void</type> * const * because it’s a mess either way you do it.

    There are Haskell libraries that autogenerate from C headers, notably bindings-GLFW, but they have to stick to weird conventions out of necessity, like prepending garbage to names and exporting functions multiple times in different formats.

    The correct way to do this would be for each C library to ship an XML with all the function signatures, otherwise I think handrolling just does the job better.

  • Automated conversion from some intermediate general format into Haskell FFI modules.

    The generation here is the the easy part, you just get Data.ByteString.Builder and make a small program that writes files. I’ll inevitably make one like this just because every FFI import currently needs to be defined twice, safe and unsafe, and freetype2 is a rather large library without an XML file.

    However, I don’t think on a community level an opinionated templating library would be enough. You’d most probably want a holistic well-documented FFI experience, and aside from the community agreeing on the one true raw binding format, it would also include:

    • An extra library like storable-offset that is the only Haskell dependency needed to produce FFI bindings. If the generator is a boot library, this one would be too. Currently I think it would only need one type class for normal struct offsets and one for bitfield offsets.

    • Cabal support: FFI libraries as a new type of dependency. This would allow both proper user-side linking (instead of the current mess) and FFI dependency sharing between higher-level libraries.

    • Haddock support: a different way to render FFI functions. C structs are not Haskell datatypes, but I still want them to look accessible instead of being rendered as a bunch of instances. Same way foreign imports are not regular Haskell functions and I would want that to be clear.

    • Hackage support: showing FFI dependencies. Libraries with such dependencies should not be expected to work out of the box. Different languages could also use slightly different webpage styles (e.g. colors), but that would be the gravy on top.

    Sounds like an RFC, doesn’t it?

6 Likes