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

[Carter Schonwald]

Hey Malcolm, that’s pretty interesting!
Is this bug reported anywhere and or has any work been sponsored for
addressing that ?

-Carter.

On Thu, May 28, 2020 at 3:38 AM Malcolm Wallace <malcolm.wallace at me.com>
wrote:

> 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/44a5ef7a/attachment.html>