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

Thu May 28 13:16:41 UTC 2020

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200528/96460976/attachment.html>