<div><div dir="auto">Agreed on AMP </div><div dir="auto"><br></div><div dir="auto">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 </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 9, 2020 at 3:59 AM David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="auto">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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 9, 2020, 3:44 AM Julian Ospald <<a href="mailto:hasufell@posteo.de" target="_blank">hasufell@posteo.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div>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. <br><br><a href="https://github.com/haskell/containers/pull/592" rel="noreferrer" target="_blank">https://github.com/haskell/containers/pull/592</a><br><br>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. <br><br><div class="gmail_quote">On June 8, 2020 4:46:17 AM UTC, David Feuer <<a href="mailto:david.feuer@gmail.com" rel="noreferrer" target="_blank">david.feuer@gmail.com</a>> wrote:<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<pre style="font-family:monospace">I really *wish* we had another viable and relevant Haskell<br>implementation we could test against. That would be *great*. The<br>containers package is quite venerable, long predating my own<br>involvement. For its entire life, it has had a tradition of trying to<br>be portable. It seems somewhat sad to throw all that away. I believe<br>there *is* an alternative option, but it will require someone to put<br>in a significant amount of work to make it happen. The basic idea is<br>to replace direct checks for __GLASGOW_HASKELL__ with ones for our own<br>version of that. Normally, __OUR_GLASGOW_HASKELL__ will be equal to<br>__GLASGOW_HASKELL__, but we can also choose to leave it undefined<br>using a Cabal option or some such. That way, we can at least run CI<br>with our "non-GHC" code and make sure that it still works.<br><br>On Sun, Jun 7, 2020 at 10:59 PM Fumiaki Kinoshita <<a href="mailto:fumiexcel@gmail.com" rel="noreferrer" target="_blank" style="font-family:monospace">fumiexcel@gmail.com</a>> wrote:<br>><br><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;font-family:monospace;border-left-color:rgb(114,159,207)"> I noticed that there are massive amount of CPP pragmas to switch code between GHC and non-GHC (e.g. <a href="https://github.com/haskell/containers/blob/v0.6.2.1/containers/src/Data/IntMap/Internal.hs#L4)," rel="noreferrer" target="_blank" style="font-family:monospace">https://github.com/haskell/containers/blob/v0.6.2.1/containers/src/Data/IntMap/Internal.hs#L4),</a> 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 (<a href="https://github.com/haskell/containers/pull/728#discussion_r436318206)." rel="noreferrer" target="_blank" style="font-family:monospace">https://github.com/haskell/containers/pull/728#discussion_r436318206).</a><br><br> 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.<hr style="font-family:monospace"> Libraries mailing list<br> <a href="mailto:Libraries@haskell.org" rel="noreferrer" target="_blank" style="font-family:monospace">Libraries@haskell.org</a><br> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank" style="font-family:monospace">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br></blockquote><hr style="font-family:monospace">Libraries mailing list<br><a href="mailto:Libraries@haskell.org" rel="noreferrer" target="_blank" style="font-family:monospace">Libraries@haskell.org</a><br><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank" style="font-family:monospace">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br></pre></blockquote></div></div></blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>