<div><div dir="auto">Hey Malcolm, that’s pretty interesting!</div></div><div dir="auto">Is this bug reported anywhere and or has any work been sponsored for addressing that ? </div><div dir="auto"><br></div><div dir="auto">-Carter. </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 28, 2020 at 3:38 AM Malcolm Wallace <<a href="mailto:malcolm.wallace@me.com">malcolm.wallace@me.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="auto">We still use ghc-7.8 at work, because it seems that every release from 8.0 onwards generates code with a catastrophic random segfault bug on Windows 64-bit.  It is to do with ghc producing code for the small memory model, but the windows DLL loader sometimes loads the code higher than the 4Gb watermark. We can’t upgrade until that is fixed.<br><br><div dir="ltr">Regards,<div>    Malcolm</div></div><div dir="ltr"><br><blockquote type="cite">On 27 May 2020, at 21:09, Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"></div></blockquote></div><div dir="auto"><blockquote type="cite"><div dir="ltr"><div><div dir="auto">When it’s super easy to support a wide ghc range I totally support it!</div></div><div dir="auto"><br></div><div dir="auto">That said , there are absolutely compiler bugs that are terrible in older ghc.  Eg in 7.6, 7.8, and 7.10.1 and 7.10.2 (fixed in 7.10.3), there’s a really nasty bug in the register allocator that mixed up float and double.  Though I can’t find the ticket atm. </div><div dir="auto"><br></div><div dir="auto">One point I realized / articulated recently is that supporting pre ghc 8.0 makes it difficult to change public data  types without breaking all current users.  Which is something pattern synonyms supports very well (I dislike how it interacts with coverage checking, but that’s a whole bother ball of wax. )</div><div dir="auto"><br></div><div dir="auto">There’s often a very real cost to supporting ever widening ranges that cover larger and large range of versions and dialects and bug workarounds.  5 years ago supporting just the three most recent ghc major versions was considered amazing. To be fair, it’s way easier to do meticulous ci across a whole matrix of ghc versions now. But it is still a no zero cost on maintainers.  </div><div dir="auto"><br></div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 27, 2020 at 2:04 PM Vanessa McHale <<a href="mailto:vamchale@gmail.com" target="_blank">vamchale@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)">I don’t drop support (that would be silly) as often as I write a new library that needs GHC >= 8.0 or sometimes GHC>7.6<br>
<br>
I use newer versions of base for unsafeDupablePerformIO and some 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 <<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 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 probably this is anyway the consensus).<br>
> <br>
> That said, I do not maintain any libraries.  Libraries should not 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 build software they actually use ? What are the contexts for these ?<br>
>> I know a lot of library maintainers, myself included try to make it easy to suport as wide a version range of ghc as possible.  In my case I find it useful to just have another way to evaluate how 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 7.0 in centos 6<br>
>> Then centos 7 and the oldest Ubuntu lts are 7.6, then more recent distros plus most other os platforms like the bsds are on 8.0-8.4 as the oldest supported / provided ghc.<br>
>> Who are the users today and how important are they for todays library maintainers ?<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>
> _______________________________________________<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>
<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>
<span>_______________________________________________</span><br><span>Libraries mailing list</span><br><span><a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a></span><br><span><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a></span><br></div></blockquote></div></blockquote></div></div>