Hi all,

I've seen and responded to a few comments regarding the direction / maintainership of the project recently that I think warrant a bigger discussion. It's fair to say that none of the maintainers, including myself, have the time to really helm and drive a project of this size to the level that it deserves, and considering that upstream LLVM continues to change and evolve, that role involves a significant amount of work.

It would be great to have some new folks take on some of this work, and gain some new maintainers who are excited to spend some time on LLVM and Haskell interaction, so I think something helpful to kick off this discussion would be just to list here the challenges that I'm currently aware of.

1. General Updates for LLVM sync -- llvm-hs tries to follow the LLVM API as closely as makes sense, and the LLVM API (and the IR itself) has grown and changed in the 2-3 years since the last updates on llvm-hs. This is relatively straightforward sync and update work, though the volume of work required could be substantial.
2. Minimising and eliminating LLVM extension code -- we have a lot of this. An underlying issue that I found when I first started digging into llvm-hs during my PhD work is that the LLVM C API, which we wrap with Haskell's FFI tooling, is a) incomplete relative the C++ API, and b) contains numerous inconsistencies which we have had to work around. For example, some LLVM C API functions incorrectly coerce types in their parameters or return values, such as taking a uint32_t parameter where the C++ API takes a uint64_t, and vice versa. llvm-hs has grown a significant amount of code in a "middleware" layer, which is C++ code written with extern C that extends and fixes the LLVM C API. This code should really be contributed back to upstream LLVM, since providing a binding for the large upstream API is already enough of a challenge, without also authoring a middleware layer with fixes and missing C++ API functionality restored.
3. Evangelizing and growing the project / user base -- there is a type of chicken-and-egg problem with the project at the moment, because wider adoption would bring more eyes and more potential maintainers, but an llvm-hs which is only really useful for targeting LLVM 12 and earlier is not really something that is very attractive to people starting new projects and hoping to use new and shiny LLVM features. For example, an obvious win for this project would be for either GHC or other well-known compilers implemented in Haskell and targeting LLVM to become users of this library, rather than using hand-rolled LLVM IR emitters / quasiquoters. I did broach this subject a couple of years ago on the GHC issue tracker, but it seems like there isn't someone who is willing to take on the time and the risk of swapping out GHC's hand-rolled LLVM integration for something more generic, particularly since this project appears to have stalled, at least as far as newer LLVM versions are concerned. Something that adopting llvm-hs in the backend would enable for GHC is the ability to easily build optimizations directly manipulating the produced LLVM IR in Haskell, rather than having to build those as C++ code in LLVM passes. A lot of information from Haskell is lost when lowering to LLVM IR, but the monadic structure of llvm-hs allows that information to be associated with the emitted IR nodes in a very nice way with stateful emission of annotations, and could enable clean Haskell implementations of GHC-specific code optimizations on the resulting LLVM IR.

If tackling some of these issues sounds like something that you, dear reader, would find interesting and rewarding work, and you have the bandwidth to spare, it would be fantastic to see the project gain some new energy. I'm very happy to add new maintainers who would be interested in tackling these or any other issues and helping to bring llvm-hs development back to life!