MicroHs support

[sol]

The goal of base-compat is to make packages compatible with a wider range of compilers.

Sadly, for MicroHs it has the opposite effect: If a package that is otherwise perfectly compatible with MicroHs uses base-compat then it does not build with MicroHs anymore.

Initial goal: Not full base-compat support, but rather find a way so that if a package:

1. depends on base-compat, and
2. only uses functionality from base-compat that is implemented in MicroHs

then the package should build with MicroHs.

(Or in other words: A package should not fail to build merely because it uses base-compat.)

I am not sure what's the best way forward here.

@RyanGlScott I'm not sure if this can be easily addressed in base-compat itself. Thoughts?

@augustss Do you think this should be addressed in MicroHs, adding .Compat aliases for each module from base and ghc-compat?

Or maybe a base-compat-mhs package?

[augustss]

I think a base-compat-mhs would be best, with just empty modules.

[RyanGlScott]

To be clear, is maintaining base-compat-mhs something that would be done in this repo, or upstream in MicroHs?

Relatedly, I see that there is a corresponding issue upstream (augustss/MicroHs#350), but it is unclear to me what the relationship between that issue and this one is.

[augustss]

There are no rules. But I'd image base-compat-mhs being maintained by people who care about mhs.

[sol]

To be clear, is maintaining base-compat-mhs something that would be done in this repo, or upstream in MicroHs?

Technically, there are two options:

1. Using a single source package to support both GHC and MicroHs.
2. Using separate implementations for GHC and MicroHs respectively.

In general, I prefer (1) over (2), just for base-compat specifically I have doubts whether it's realistically feasible.

@RyanGlScott I still wanted to get your input before we settle on option (2), that's why I opened this issue first.

If it's option (2) then I think it should be in the MicroHs repository (my personal preference), or in a separate repository and we can probably move this discussion over to augustss/MicroHs#350.

Relatedly, I see that there is a corresponding issue upstream (augustss/MicroHs#350), but it is unclear to me what the relationship between that issue and this one is.

My intention is to keep people who are only watching the MicroHs repository in the loop.

[RyanGlScott]

I am also fine with option (2), i.e., using a separate implementation for base-compate-mhs. Maintaining base-compat requires a somewhat deep understanding of base's internals, and since I don't have any experience in dealing with MicroHs's version of base, I suspect that I would likely be a bottleneck in keeping the library up to date with MicroHs changes.

I'm open to revisiting this arrangement in the future—perhaps it might make sense to eventually bring base-compat-mhs under the same organization as base-compat. I'm inclined to see wait and see how base-compat-mhs evolves first.