Strategies for increasing the number of Hackage packages that are not GHC specific

[stevana]

I thought a bit about the problem of most packages on Hackage being GHC specific, and it made me realise: even if I wanted to write non-GHC specific code (i.e. code that would work with e.g. MicroHs) it's not easy for me to assure that I do.

Two things that came to my mind, that I think would be helpful:

1. If there was an easy way do add MicroHs to the CI of my library;
2. Is there a way to set up a .cabal file so that even when compiling with GHC, we know that it should work with MicroHs? For example, if I set default-language: Haskell2010 in cabal, it will still let me depend on code that doesn't follow Haskell2010, right? Or even GHC specific modules from base?

I suppose 1) is a matter of packing MicroHs up in a GitHub action, or extending the haskell-actions/setup action, while 2) I guess would require changing cabal/GHC? So technically this isn't a MicroHs issue, but on the other hand I suppose nobody except for MicroHs user care, hence posting it here (feel free to close if you find it off topic).

I'm also curious if there are other (better) ways we can make it easier for people to write non-GHC specific libraries?

[augustss]

1. This is not as easy as it should be, but it can be done. Check out the hackage-ci github action in MicroHs.

2. This would need some changes to Cabal to find out what the transitive dependencies are.
   Even then it would not be easy, since MicroHs pretends to have certain features, like the Lift class in TH.
   The reason being that without this, many more packages would need conditional compilation.

[stevana]

I suppose another way to put 2) is: while in e.g. gcc if you pass -std=c90 it will disable features which are not in the standard, while in GHC setting default-language: Haskell2010 will enable features that are in the standard (and it will even let you enable further features).