<html><head></head><body>Portability is the reason I stopped caring about my containers PR, which is a very minor addition. I have no concrete input on what to do either, even after several pings, so I gave up. <br><br><a href="https://github.com/haskell/containers/pull/592">https://github.com/haskell/containers/pull/592</a><br><br>My view on this is: if it makes people stop contributing, it is not worth it for something I don't even see a real world use case for, only theoretical ones. <br><br><div class="gmail_quote">On June 8, 2020 4:46:17 AM UTC, David Feuer <david.feuer@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">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 <fumiexcel@gmail.com> wrote:<br>><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> 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),">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).">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.<hr> Libraries mailing list<br> Libraries@haskell.org<br> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br></blockquote><hr>Libraries mailing list<br>Libraries@haskell.org<br><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br></pre></blockquote></div></body></html>