Question about the portability of containers

[Julian Ospald]

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. 

https://github.com/haskell/containers/pull/592

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. 

On June 8, 2020 4:46:17 AM UTC, David Feuer <david.feuer at gmail.com> wrote:
>I really *wish* we had another viable and relevant Haskell
>implementation we could test against. That would be *great*. The
>containers package is quite venerable, long predating my own
>involvement. For its entire life, it has had a tradition of trying to
>be portable. It seems somewhat sad to throw all that away. I believe
>there *is* an alternative option, but it will require someone to put
>in a significant amount of work to make it happen. The basic idea is
>to replace direct checks for __GLASGOW_HASKELL__ with ones for our own
>version of that. Normally, __OUR_GLASGOW_HASKELL__ will be equal to
>__GLASGOW_HASKELL__, but we can also choose to leave it undefined
>using a Cabal option or some such. That way, we can at least run CI
>with our "non-GHC" code and make sure that it still works.
>
>On Sun, Jun 7, 2020 at 10:59 PM Fumiaki Kinoshita <fumiexcel at gmail.com>
>wrote:
>>
>> I noticed that there are massive amount of CPP pragmas to switch code
>between GHC and non-GHC (e.g.
>https://github.com/haskell/containers/blob/v0.6.2.1/containers/src/Data/IntMap/Internal.hs#L4),
>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
>(https://github.com/haskell/containers/pull/728#discussion_r436318206).
>>
>> 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.
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>_______________________________________________
>Libraries mailing list
>Libraries at haskell.org
>http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200609/cccc38b6/attachment.html>