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 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 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/IntM...), 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

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 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 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 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 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/IntM...), 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