Question about the portability of containers

[Carter Schonwald]

Agreed on AMP

In a discussion a while back, it seemed like dropping support for pre 7.10
was something many maintainers and users were comfortable with.  Not
universally. But definitely something that’s an option if it sheds enough
complexity for maintainers and contributors.  Heck in some cases folks are
happy to have >=8.0 or 8.2




On Tue, Jun 9, 2020 at 3:59 AM David Feuer <david.feuer at gmail.com> wrote:

> Sorry, I got busy with other things and didn't finish following up on that
> PR. The Applicative/Monad thing will be cleared up automatically whenever
> we drop support for GHC 7.8. It's hard to imagine a future Haskell
> implementation without AMP.
>
> On Tue, Jun 9, 2020, 3:44 AM Julian Ospald <hasufell at posteo.de> wrote:
>
>> 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
>>>
>>> _______________________________________________
> 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/984e6a70/attachment.html>