What Haskell users are actively maintaining or deving software using ghc <8

[Malcolm Wallace]

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.

Regards,
    Malcolm

> On 27 May 2020, at 21:09, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> 
> 
> When it’s super easy to support a wide ghc range I totally support it!
> 
> 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. 
> 
> 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. )
> 
> 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.  
> 
> 
> 
>> On Wed, May 27, 2020 at 2:04 PM Vanessa McHale <vamchale at gmail.com> wrote:
>> 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
>> 
>> I use newer versions of base for unsafeDupablePerformIO and some lazy ST monad features I think
>> 
>> I’d definitely consider older GHCs if there’s enthusiasm. 
>> 
>> Cheers,
>> 
>> > On May 27, 2020, at 12:55 PM, Andreas Abel <andreas.abel at ifi.lmu.de> wrote:
>> > 
>> > I am using ghc 7.6 and up.  I dropped support for ghc 7.4 and below because I fancy
>> > 
>> >  \case
>> > 
>> > which is new in 7.6.
>> > 
>> > I'd say there is little reason to support ghc 6 any longer (but probably this is anyway the consensus).
>> > 
>> > That said, I do not maintain any libraries.  Libraries should not drop ghc versions lightly.
>> > 
>> > On 2020-05-27 16:50, Carter Schonwald wrote:
>> >> Hey all,
>> >> What are the oldest ghc versions folks are actually using to build software they actually use ? What are the contexts for these ?
>> >> 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.
>> >> That said, what actual old ghc versions are folks actually using?
>> >> Afaict, the oldest ghc currently in a lts linux distro is ghc 7.0 in centos 6
>> >> 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.
>> >> Who are the users today and how important are they for todays library maintainers ?
>> >> _______________________________________________
>> >> Libraries mailing list
>> >> Libraries at haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> 
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200528/f957b35a/attachment.html>