Question about the portability of containers

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about the portability of containers

Fumiaki Kinoshita
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Question about the portability of containers

David Feuer
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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Question about the portability of containers

Henning Thielemann
In reply to this post by Fumiaki Kinoshita

On Mon, 8 Jun 2020, Fumiaki Kinoshita wrote:

> 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.

The problem is: The less portable libraries we have, the less useful is
any new compiler. I do not use any CPP for my libraries. I always use
Cabal flags to switch between two Hs-Source-Dirs containing different
implementations of some (not all) modules. This way, you could easily
switch to the portable implementation also for GHC.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Question about the portability of containers

Fumiaki Kinoshita
In reply to this post by David Feuer
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's an interesting trick.

2020年6月8日(月) 13:46 David Feuer <[hidden email]>:
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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Question about the portability of containers

Julian Ospald
In reply to this post by David Feuer
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Question about the portability of containers

David Feuer
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries