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

Thu May 28 16:33:00 UTC 2020

Very good point!

On Thu, May 28, 2020 at 9:17 AM Callan McGill <callan.mcgill at gmail.com>
wrote:

> > although the "proper" way of library design would be not to export
> constructors in the first place, but use abstract data types."
>
> 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.
>
> Best,
> Callan
>
> On Thu, 28 May 2020 at 03:22, Andreas Abel <andreas.abel at ifi.lmu.de>
> wrote:
>
>> @Carter: A hackage crawler could probably give a good answer to your
>> original question.
>>
>> PatternSynonyms were introduced in 7.8 (but maybe didn't work 100% from
>> the start).  I also consider PatternSynonyms a major improvement;
>> although the "proper" way of library design would be not to export
>> constructors in the first place, but use abstract data types.  In
>> practice, few have the discipline, though.
>>
>> GHC development is unfortunately not monotone, e.g. here is a bug
>> introduced in 8.4 and fixed in 8.8:
>>
>>    https://github.com/agda/agda/issues/4100
>>
>> A solution here would be to backport bug fixes, but the community does
>> not have the resources to do this.
>>
>>  > 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.
>>
>> I agree.
>>
>> In general, Haskell is a very nervous language, with lots of changes all
>> the time.  This seems to be the fate of a language that is both a
>> science lab for programming language research and a language people use
>> for serious development.
>> I'd hope for a slower breakage rate on the side of the syntax and the
>> standard library.
>>
>> I also hope that Haskell 2020 will surface and cut a bit off the
>> language extension forest.
>>
>>
>> On 2020-05-27 22:08, Carter Schonwald 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
>> > <mailto: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 <mailto: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 <mailto:Libraries at haskell.org>
>> >      >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> >      > _______________________________________________
>> >      > Libraries mailing list
>> >      > Libraries at haskell.org <mailto:Libraries at haskell.org>
>> >      > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> >
>> >     _______________________________________________
>> >     Libraries mailing list
>> >     Libraries at haskell.org <mailto: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/30eeb677/attachment.html>