-
Notifications
You must be signed in to change notification settings - Fork 37
Description
Before I explain why I want to do this, let me first make some observations about singletons-base's minimum GHC requirements.
Historically speaking, singletons-base has always been tied to a particular GHC version, as its implementation almost always requires the latest version of GHC to build. Or, at the very least, to build without needing heavy amounts of CPP. While this has been true of every singletons release that I can recall, GHC 9.4 is, remarkably, not that different from 9.2 in terms of its impact on singletons-base. In fact, one can compile the current state of the master branch with both 9.2 and 9.4, requiring no other changes than some minor changes to version bounds.
This is pretty remarkable, and I think it would be worth considering making the next release of singletons-base build with both GHC 9.2 and 9.4, given how straightforward it would be to do so. There's only one sticking point with this plan that I am aware of: the singletons-base test suite. The output of this test suite is intimately tied to one particular GHC version, and indeed, the output of the test suite changes depending on whether you use 9.2 or 9.4. Granted, it's mostly whitespace and formatting changes (e.g., rendering Type instead of Data.Kind.Type), but these are changes nonetheless.
I think it would be a shame to have the test suite be the sole reason why we can't widen the support window for singletons-base a little. In light of this, I propose that we split out the singletons-base test suite into its own singletons-base-tests package. The GHC support window for singletons-base-tests would be even tighter than it would be for singletons-base. We could continue to run the test suite in CI, and we could even upload singletons-base-tests to Hackage so that those who want to run it themselves can continue to do so.
Aside from the GHC support window benefits, another benefit to doing this is that singletons-base would no longer require a custom Setup.hs script; only singletons-base-tests would. Custom Setup.hs scripts often pose issues for things like cross-compilation, so this seems like a natural way to remove that roadblock.