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

28 May 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  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 mailto:vamchale@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
    mailto:andreas.abel@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@haskell.org mailto:Libraries@haskell.org
     >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
     > _______________________________________________
     > Libraries mailing list
     > Libraries@haskell.org mailto:Libraries@haskell.org
     > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
    Libraries mailing list
    Libraries@haskell.org mailto:Libraries@haskell.org
    http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

Callan McGill