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

Thu May 28 16:40:41 UTC 2020

Yeah, or incomplete APIs that don't expose the full functionality the 
data types offer...

On 2020-05-28 15:16, Callan McGill 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 
> <mailto: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>
>      > <mailto: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>
>     <mailto: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>
>     <mailto: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>
>     <mailto: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>
>     <mailto: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
> 