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@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@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@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@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries