<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The basic idea is<br>to replace direct checks for __GLASGOW_HASKELL__ with ones for our own<br>version of that. Normally, __OUR_GLASGOW_HASKELL__ will be equal to<br>__GLASGOW_HASKELL__, but we can also choose to leave it undefined<br>using a Cabal option or some such.</blockquote><div><br></div><div>That's an interesting trick.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2020年6月8日(月) 13:46 David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I really *wish* we had another viable and relevant Haskell<br>
implementation we could test against. That would be *great*. The<br>
containers package is quite venerable, long predating my own<br>
involvement. For its entire life, it has had a tradition of trying to<br>
be portable. It seems somewhat sad to throw all that away. I believe<br>
there *is* an alternative option, but it will require someone to put<br>
in a significant amount of work to make it happen. The basic idea is<br>
to replace direct checks for __GLASGOW_HASKELL__ with ones for our own<br>
version of that. Normally, __OUR_GLASGOW_HASKELL__ will be equal to<br>
__GLASGOW_HASKELL__, but we can also choose to leave it undefined<br>
using a Cabal option or some such. That way, we can at least run CI<br>
with our "non-GHC" code and make sure that it still works.<br>
<br>
On Sun, Jun 7, 2020 at 10:59 PM Fumiaki Kinoshita <<a href="mailto:fumiexcel@gmail.com" target="_blank">fumiexcel@gmail.com</a>> wrote:<br>
><br>
> I noticed that there are massive amount of CPP pragmas to switch code between GHC and non-GHC (e.g. <a href="https://github.com/haskell/containers/blob/v0.6.2.1/containers/src/Data/IntMap/Internal.hs#L4" rel="noreferrer" target="_blank">https://github.com/haskell/containers/blob/v0.6.2.1/containers/src/Data/IntMap/Internal.hs#L4</a>), and they are a burden for maintainers. Moreover, the non-GHC part of the codebase is untested due to the lack of viable alternative compilers (<a href="https://github.com/haskell/containers/pull/728#discussion_r436318206" rel="noreferrer" target="_blank">https://github.com/haskell/containers/pull/728#discussion_r436318206</a>).<br>
><br>
> Therefore I propose to revisit the policy for portability of core libraries. Portability is not a bad thing, but few people use other compilers these days. The drag is only likely to increase because there's no plan (AFAIK) for a new Haskell standard.<br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>