<div><div dir="auto">Very good point!</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 28, 2020 at 9:17 AM Callan McGill <<a href="mailto:callan.mcgill@gmail.com">callan.mcgill@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><div><div>> although the "proper" way of library design would be not to export <br>
constructors in the first place, but use abstract data types."<br><br></div>I frequently run into the opposite problem: whenever I see someone try this they don't have a separate internal or unsafe module that does expose the constructor meaning you are prohibited from using coerce or deriving via.<br><br></div>Best,<br></div>Callan<br></div></div><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 28 May 2020 at 03:22, Andreas Abel <<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">@Carter: A hackage crawler could probably give a good answer to your <br>
original question.<br>
<br>
PatternSynonyms were introduced in 7.8 (but maybe didn't work 100% from <br>
the start). I also consider PatternSynonyms a major improvement; <br>
although the "proper" way of library design would be not to export <br>
constructors in the first place, but use abstract data types. In <br>
practice, few have the discipline, though.<br>
<br>
GHC development is unfortunately not monotone, e.g. here is a bug <br>
introduced in 8.4 and fixed in 8.8:<br>
<br>
<a href="https://github.com/agda/agda/issues/4100" rel="noreferrer" target="_blank">https://github.com/agda/agda/issues/4100</a><br>
<br>
A solution here would be to backport bug fixes, but the community does <br>
not have the resources to do this.<br>
<br>
> To be fair, it’s way easier to do meticulous ci across a whole matrix <br>
of ghc versions now. But it is still a no zero cost on maintainers.<br>
<br>
I agree.<br>
<br>
In general, Haskell is a very nervous language, with lots of changes all <br>
the time. This seems to be the fate of a language that is both a <br>
science lab for programming language research and a language people use <br>
for serious development.<br>
I'd hope for a slower breakage rate on the side of the syntax and the <br>
standard library.<br>
<br>
I also hope that Haskell 2020 will surface and cut a bit off the <br>
language extension forest.<br>
<br>
<br>
On 2020-05-27 22:08, Carter Schonwald wrote:<br>
> When it’s super easy to support a wide ghc range I totally support it!<br>
> <br>
> That said , there are absolutely compiler bugs that are terrible in <br>
> older ghc. Eg in 7.6, 7.8, and 7.10.1 and 7.10.2 (fixed in 7.10.3), <br>
> there’s a really nasty bug in the register allocator that mixed up float <br>
> and double. Though I can’t find the ticket atm.<br>
> <br>
> One point I realized / articulated recently is that supporting pre ghc <br>
> 8.0 makes it difficult to change public data types without breaking all <br>
> current users. Which is something pattern synonyms supports very well <br>
> (I dislike how it interacts with coverage checking, but that’s a whole <br>
> bother ball of wax. )<br>
> <br>
> There’s often a very real cost to supporting ever widening ranges that <br>
> cover larger and large range of versions and dialects and bug <br>
> workarounds. 5 years ago supporting just the three most recent ghc <br>
> major versions was considered amazing. To be fair, it’s way easier to do <br>
> meticulous ci across a whole matrix of ghc versions now. But it is still <br>
> a no zero cost on maintainers.<br>
> <br>
> <br>
> <br>
> On Wed, May 27, 2020 at 2:04 PM Vanessa McHale <<a href="mailto:vamchale@gmail.com" target="_blank">vamchale@gmail.com</a> <br>
> <mailto:<a href="mailto:vamchale@gmail.com" target="_blank">vamchale@gmail.com</a>>> wrote:<br>
> <br>
> I don’t drop support (that would be silly) as often as I write a new<br>
> library that needs GHC >= 8.0 or sometimes GHC>7.6<br>
> <br>
> I use newer versions of base for unsafeDupablePerformIO and some<br>
> lazy ST monad features I think<br>
> <br>
> I’d definitely consider older GHCs if there’s enthusiasm.<br>
> <br>
> Cheers,<br>
> <br>
> > On May 27, 2020, at 12:55 PM, Andreas Abel<br>
> <<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a> <mailto:<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a>>> wrote:<br>
> ><br>
> > I am using ghc 7.6 and up. I dropped support for ghc 7.4 and<br>
> below because I fancy<br>
> ><br>
> > \case<br>
> ><br>
> > which is new in 7.6.<br>
> ><br>
> > I'd say there is little reason to support ghc 6 any longer (but<br>
> probably this is anyway the consensus).<br>
> ><br>
> > That said, I do not maintain any libraries. Libraries should not<br>
> drop ghc versions lightly.<br>
> ><br>
> > On 2020-05-27 16:50, Carter Schonwald wrote:<br>
> >> Hey all,<br>
> >> What are the oldest ghc versions folks are actually using to<br>
> build software they actually use ? What are the contexts for these ?<br>
> >> I know a lot of library maintainers, myself included try to make<br>
> it easy to suport as wide a version range of ghc as possible. In my<br>
> case I find it useful to just have another way to evaluate how<br>
> stable I can make a library.<br>
> >> That said, what actual old ghc versions are folks actually using?<br>
> >> Afaict, the oldest ghc currently in a lts linux distro is ghc<br>
> 7.0 in centos 6<br>
> >> Then centos 7 and the oldest Ubuntu lts are 7.6, then more<br>
> recent distros plus most other os platforms like the bsds are on<br>
> 8.0-8.4 as the oldest supported / provided ghc.<br>
> >> Who are the users today and how important are they for todays<br>
> library maintainers ?<br>
> >> _______________________________________________<br>
> >> Libraries mailing list<br>
> >> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a> <mailto:<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>
> > _______________________________________________<br>
> > Libraries mailing list<br>
> > <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a> <mailto:<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>
> <br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a> <mailto:<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>
> <br>
_______________________________________________<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><div dir="ltr"></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>