Add section about portability

[mpickering]

I have added a section to the README which explains how platform portability should be a key consideration for the maintenance of core libraries.

There have been a couple of instances recently where TemplateHaskell has been used in core libraries which had meant they couldn't be built on some platforms. It seems helpful to just write down what the expectations are for maintainers of core libraries so they remain usable for everyone!

• Remove usage of QuasiQuotes directory#193
• Use TemplateHaskellQuotes rather than TemplateHaskell extension os-string#21

[hasufell]

Could you expand what platforms exactly and why they can't use TH? Isn't that a GHC bug?

[AndreasPK]

Both the JS and Wasm backend had and still have varying levels of support for TH to my knowledge. It's actively being worked on but that doesn't really help users today.

A good setup for cross compilation which supports TH also remains complex to set up.

So refraining from the use of TH when it's easy to do seems like a sensible approach for core libraries to me.

[hsyl20]

Could you expand what platforms exactly and why they can't use TH? Isn't that a GHC bug?

Stage1 GHC can't use the internal interpreter by design: it builds objects with a different ABI than its own. So using TH splices in Core libs that need to be built with stage1 is deemed to fail.

We might use the external interpreter instead but:

• it's a bit of a pain to setup currently
• it wouldn't work for cross-compiling a GHC (we would need to setup qemu/wine/iserv-proxy which is an even higher level of pain)

JS isn't even the worse here: it supports TH in Stage1 because it never uses the internal interpreter and because it has its own external interpreter that is automatically setup and used (via NodeJS).

[hasufell]

It seems helpful to just write down what the expectations are for maintainers of core libraries

We should also write down the expectations that core library maintainers have of GHC HQ.

[Bodigrim]

Unfortunately, I don't have bandwidth to discuss the proposal with maintainers of core libraries and I don't feel like imposing additional obligations unilateraly (even if very reasonable ones) is healthy. The proposed obligations make sense to some boot libraries (but not to all, Win32 and unix are certainly not portable), but in general I don't see why CLC would be shy to adopt platform-specific or TH-based libraries.

I understand the underlying concern, but I think it's already covered by the current text. If a boot library cannot be built by GHC bootstrapping process and fails to accept contributions rectifying the matter, then it is not in "appropriate shape" and one can appeal to CLC to fix it.

core-libraries-committee/README.md

Lines 79 to 84 in 7ad3ecf

	Maintainers of Core Libraries may at their own accord seek CLC approval for
	controversial changes, but are not required to do so. CLC does not interfere
	with daily development of Core Libraries as long as appointed maintainers
	keep them in an appropriate shape and support healthy communication with
	contributors. If CLC finds a Core Library in a neglected state, it can
	source and install new maintainers or resolve situation by other means.