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

newer
Parsing Ratio with zero denominator

Carter Schonwald

27 May 2020 27 May '20

2:50 p.m.

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 ?

Attachments:

attachment.html (text/html — 1.0 KB)

Show replies by date

Henning Thielemann

27 May 27 May

3:09 p.m.

On Wed, 27 May 2020, Carter Schonwald wrote:

...

Who are the users today and how important are they for todays library maintainers ?

I use 7.4.2 regularly. I like to avoid upgrading to 7.10 and above because I do not want to run into accidental bugs based on "maximum (a,b)". However, I have installed down to 7.0 and up to 8.10 via HVR's PPA for Ubuntu for testing purposes.

Joseph C. Sible

8:33 p.m.

On Wed, May 27, 2020 at 11:09 AM Henning Thielemann wrote:

...

I use 7.4.2 regularly. I like to avoid upgrading to 7.10 and above because I do not want to run into accidental bugs based on "maximum (a,b)".

IMO, avoiding "instance Foldable ((,) a)" isn't really a good reason to not upgrade. You're giving up a lot of bug fixes and other improvements just to avoid accidentally writing code that a linter will easily catch. Joseph C. Sible

amindfv＠gmail.com

8:53 p.m.

...

El 27 may 2020, a las 16:33, Joseph C. Sible escribió:

On Wed, May 27, 2020 at 11:09 AM Henning Thielemann wrote:

...
I use 7.4.2 regularly. I like to avoid upgrading to 7.10 and above because I do not want to run into accidental bugs based on "maximum (a,b)".

IMO, avoiding "instance Foldable ((,) a)" isn't really a good reason to not upgrade. You're giving up a lot of bug fixes and other improvements just to avoid accidentally writing code that a linter will easily catch.

The problems with (Foldable (,)) run much deeper than a liner could catch, as far as I'm aware. Although I use 8.4+ myself, I try to support 7.4+ in my packages specifically for people who are holding out for a real solution to the problem. Though LambdaCase is sometimes too good to lose! Tom

Henning Thielemann

9:27 p.m.

On Wed, 27 May 2020, Joseph C. Sible wrote:

...

On Wed, May 27, 2020 at 11:09 AM Henning Thielemann wrote:

...
I use 7.4.2 regularly. I like to avoid upgrading to 7.10 and above because I do not want to run into accidental bugs based on "maximum (a,b)".

IMO, avoiding "instance Foldable ((,) a)" isn't really a good reason to not upgrade. You're giving up a lot of bug fixes and other improvements just to avoid accidentally writing code that a linter will easily catch.

I am not giving up anything, because I test my code against both 7.4.2 AND newer GHC versions. What linter can easily catch "instance Foldable ((,) a)"? GHC cannot warn about it, so far. Another solution would be to separate 'base' from GHC. I could then work with a patched 'base' with forbidden "instance Foldable ((,) a)".

Joseph C. Sible

10:19 p.m.

On Wed, May 27, 2020 at 5:27 PM Henning Thielemann wrote:

...

I am not giving up anything, because I test my code against both 7.4.2 AND newer GHC versions.

You're giving up the ability to use every new feature introduced since then, since using them would mean your code stops working under 7.4.2.

...

What linter can easily catch "instance Foldable ((,) a)"?

HLint can: for example, if you run hlint on a file containing "foo = maximum (4,2)", it says "Warning: Using maximum on tuple" Joseph C. Sible

Henning Thielemann

10:26 p.m.

On Wed, 27 May 2020, Joseph C. Sible wrote:

...

On Wed, May 27, 2020 at 5:27 PM Henning Thielemann wrote:

...
What linter can easily catch "instance Foldable ((,) a)"?

HLint can: for example, if you run hlint on a file containing "foo = maximum (4,2)", it says "Warning: Using maximum on tuple"

maximum . (f&&&g) ?

amindfv＠gmail.com

10:41 p.m.

...

El 27 may 2020, a las 18:19, Joseph C. Sible escribió:

On Wed, May 27, 2020 at 5:27 PM Henning Thielemann wrote:

...
I am not giving up anything, because I test my code against both 7.4.2 AND newer GHC versions.

You're giving up the ability to use every new feature introduced since then, since using them would mean your code stops working under 7.4.2.

...
What linter can easily catch "instance Foldable ((,) a)"?

HLint can: for example, if you run hlint on a file containing "foo = maximum (4,2)", it says "Warning: Using maximum on tuple"

maxRatio l = maximum l / toEnum (length l) main = do print $ maxRatio [1..5] -- Imagine after some refactoring you're passing around a tuple instead: print $ maxRatio ([1..5], 5)

Ben Gamari

28 May 28 May

5:06 a.m.

Henning Thielemann writes:

...

On Wed, 27 May 2020, Joseph C. Sible wrote:

...
On Wed, May 27, 2020 at 11:09 AM Henning Thielemann wrote:

...
I use 7.4.2 regularly. I like to avoid upgrading to 7.10 and above because I do not want to run into accidental bugs based on "maximum (a,b)".

IMO, avoiding "instance Foldable ((,) a)" isn't really a good reason to not upgrade. You're giving up a lot of bug fixes and other improvements just to avoid accidentally writing code that a linter will easily catch.

I am not giving up anything, because I test my code against both 7.4.2 AND newer GHC versions.

What linter can easily catch "instance Foldable ((,) a)"?

GHC cannot warn about it, so far.

Another solution would be to separate 'base' from GHC. I could then work with a patched 'base' with forbidden "instance Foldable ((,) a)".

For what it's worth, I suspect there are a few solutions to the problem of disallowing use of particular instances which may be close-at-hand: * Providing a compiler flag or pragma to "poison" an instance, locally preventing the compiler from using it as evidence; this would require a GHC proposal and may not be entirely trivial to implement, but it's certainly feasible. * Providing a GHC source plugin that would look for dictionaries of type (e.g.) Foldable ((,) a) in the desugared Core of a module and report them as errors * Using GHC's HIE output to implement a linter which would identify above-mentioned dictionaries. Cheers, - Ben

Henning Thielemann

5:06 p.m.

New subject: catch instance Foldable ((, ) a) (Was: What Haskell users are actively maintaining or deving software using ghc <8)

On Thu, 28 May 2020, Ben Gamari wrote:

...

Henning Thielemann writes:

...
What linter can easily catch "instance Foldable ((,) a)"?

GHC cannot warn about it, so far.

Another solution would be to separate 'base' from GHC. I could then work with a patched 'base' with forbidden "instance Foldable ((,) a)".

For what it's worth, I suspect there are a few solutions to the problem of disallowing use of particular instances which may be close-at-hand:

* Providing a compiler flag or pragma to "poison" an instance, locally preventing the compiler from using it as evidence; this would require a GHC proposal and may not be entirely trivial to implement, but it's certainly feasible.

https://gitlab.haskell.org/ghc/ghc/issues/11796

...

* Providing a GHC source plugin that would look for dictionaries of type (e.g.) Foldable ((,) a) in the desugared Core of a module and report them as errors

Interesting idea. Or would it be better implemented in a type-checker plugin?

...

* Using GHC's HIE output to implement a linter which would identify above-mentioned dictionaries.

Ben Gamari

29 May 29 May

3:47 a.m.

New subject: catch instance Foldable ((, ) a) (Was: What Haskell users are actively maintaining or deving software using ghc <8)

Henning Thielemann writes:

...

On Thu, 28 May 2020, Ben Gamari wrote:

...
Henning Thielemann writes:

...
What linter can easily catch "instance Foldable ((,) a)"?

GHC cannot warn about it, so far.

Another solution would be to separate 'base' from GHC. I could then work with a patched 'base' with forbidden "instance Foldable ((,) a)".

For what it's worth, I suspect there are a few solutions to the problem of disallowing use of particular instances which may be close-at-hand:

* Providing a compiler flag or pragma to "poison" an instance, locally preventing the compiler from using it as evidence; this would require a GHC proposal and may not be entirely trivial to implement, but it's certainly feasible.

https://gitlab.haskell.org/ghc/ghc/issues/11796

Indeed. All we need is someone to implement. Admittedly, I don't have much insight into how difficult this would be. Richard or Simon would likely be more helpful in this regard.

...

...
* Providing a GHC source plugin that would look for dictionaries of type (e.g.) Foldable ((,) a) in the desugared Core of a module and report them as errors

Interesting idea. Or would it be better implemented in a type-checker plugin?

That would be another approach but I don't believe this is possible with our current typechecker plugin mechanism.. Specifically, I don't think you can currently hide existing instances. In principle your plugin could solve the unwanted instance with a TypeError but I'm not sure whether this would work reliably with GHC's current implementation: I believe that typechecker plugins are currently a fallback looked at after the usual paths have failed. Moreover, even if it does work we don't that guarantee solver behavior won't change in the future. Cheers, - Ben

Richard Eisenberg

2:09 p.m.

New subject: catch instance Foldable ((, ) a) (Was: What Haskell users are actively maintaining or deving software using ghc <8)

...

On May 29, 2020, at 4:47 AM, Ben Gamari wrote:

...
https://gitlab.haskell.org/ghc/ghc/issues/11796

Indeed. All we need is someone to implement. Admittedly, I don't have much insight into how difficult this would be. Richard or Simon would likely be more helpful in this regard.

Implementation should be quite easy. The challenge is in the design. The design in the ticket looks plausible, but you would have to start by making a GHC proposal.

...

...
Interesting idea. Or would it be better implemented in a type-checker plugin?

That would be another approach but I don't believe this is possible with our current typechecker plugin mechanism..

I agree with everything Ben said here. We look to plugins only after GHC has failed internally. Maybe that's not the best design, but it's what we have. Richard

Zemyla

2:34 p.m.

New subject: catch instance Foldable ((, ) a) (Was: What Haskell users are actively maintaining or deving software using ghc <8)

I am opposed to all the hate on Foldable ((,) a). For one thing, it's the parent of the perfectly good Traversable ((,) a) instance. For another, typeclasses should be defined for every type which has a valid and sensical instance, so people don't run into "Why isn't this defined?" and having to write orphan instances for it. For another, it just feels like the majority of it is directed at "length ('a', 1)" returning 1 instead of 2. But does anyone expect "foldr (+) 0 ('a', 1)" to return "'a'+1+0" as if that were even a thing? People don't seem to have a problem with the Functor instance for ((,) a) only mapping over the second value, and the Applicative and Monad instances treat the first argument entirely differently from the second. It's a failure of expectations more than anything else, and I really don't think anyone beyond beginner level is routinely running into bugs because they tried to use length or toList on a tuple. On Fri, May 29, 2020, 09:10 Richard Eisenberg wrote:

...

...
On May 29, 2020, at 4:47 AM, Ben Gamari wrote:

...
https://gitlab.haskell.org/ghc/ghc/issues/11796

Indeed. All we need is someone to implement. Admittedly, I don't have much insight into how difficult this would be. Richard or Simon would likely be more helpful in this regard.

Implementation should be quite easy. The challenge is in the design. The design in the ticket looks plausible, but you would have to start by making a GHC proposal.

...
...
Interesting idea. Or would it be better implemented in a type-checker plugin?

That would be another approach but I don't believe this is possible with our current typechecker plugin mechanism..

I agree with everything Ben said here. We look to plugins only after GHC has failed internally. Maybe that's not the best design, but it's what we have.

Richard _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Henning Thielemann

2:43 p.m.

New subject: catch instance Foldable ((, ) a)

On Fri, 29 May 2020, Zemyla wrote:

...

I am opposed to all the hate on Foldable ((,) a).

It's not about hate, but in _my_ code using an instance like Foldable ((,) a) or Functor ((,) a) or Traversable ((,) a) is a bug, because I would not use it by intention. That's why I want at least a warning, where there was a type error before GHC-7.10. In my code I would define a custom data type data Decorated a b = Decorated a b instead of generic pair or I would use Writer monad, if that's appropriate.

...

It's a failure of expectations more than anything else, and I really don't think anyone beyond beginner level is routinely running into bugs because they tried to use length or toList on a tuple.

You can also call it a beginner's problem to use tuples everywhere, where custom data types would be the better choice.

Zemyla

2:54 p.m.

New subject: catch instance Foldable ((, ) a)

On Fri, May 29, 2020, 09:43 Henning Thielemann < lemming@henning-thielemann.de> wrote:

...

You can also call it a beginner's problem to use tuples everywhere, where custom data types would be the better choice.

Except the Prelude uses tuples everywhere, as do hundreds of libraries based on it, and rewriting all the functions which use them for every single decorated data type you plan to use is a waste of programmer time and effort.

...

Andreas Abel

8:24 p.m.

New subject: catch instance Foldable ((, ) a)

Tuples are defined in the Prelude, but not used "everywhere". The only uses are when a function returns several results, like in splitting list, quotrem etc. These are perfectly fine uses of tuples. Tuples are for short-lived aggregations of data. Longer living aggregations deserved telling names for the sake of code comprehension. In our project Agda we have tons of clones of Bool, Maybe, Either, and (,) for the sake of giving telling names to data representations. In short sight this is a "waste of programmer time and effort", but in long sight this is a major productivity boost. We want to be able to read and maintain our code written in the 2000s still in the 2020s, and hopefully 2030s and 2040s. When you want to "traverse" it is maybe time to name your tuple. Btw. ((,) a) is more than a Traversable, it is a "Decoration": https://github.com/agda/agda/blob/c5a36ee4ef4780d0c2980a4e1a04355239c42f34/s... It commutes with every Functor, not just with any Applicative. In the end it comes down what you want to produce. For quick prototypes and throw-away tools it is fine to use Bool, Maybe, Either and tuples, but for long-living software I can only recommend to abstain. Best, Andreas On 2020-05-29 16:54, Zemyla wrote:

...

On Fri, May 29, 2020, 09:43 Henning Thielemann mailto:lemming@henning-thielemann.de> wrote:

You can also call it a beginner's problem to use tuples everywhere, where custom data types would be the better choice.

Except the Prelude uses tuples everywhere, as do hundreds of libraries based on it, and rewriting all the functions which use them for every single decorated data type you plan to use is a waste of programmer time and effort.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Sven Panne

2:59 p.m.

New subject: catch instance Foldable ((, ) a) (Was: What Haskell users are actively maintaining or deving software using ghc <8)

Am Fr., 29. Mai 2020 um 16:35 Uhr schrieb Zemyla :

...

I am opposed to all the hate on Foldable ((,) a). For one thing, it's the parent of the perfectly good Traversable ((,) a) instance. [...]

Please don't restart the epic discussion on this issue. For quite a lot of people there is *nothing* good at all regarding the FTP instances for tuples, and their slightly stealthy way into the base library happened only after this was widely recognized. So a compromise is to let the instances live and provide a way to disallow them for your own code.

Helmut Schmidt

27 May 27 May

3:25 p.m.

It's nice to verify that my code still works with GHC 7.0 which to my knowledge is the GHC version most compliant to the published Haskell 2010 Report. But I realize that nowadays making do with plain Haskell 2010 and without all those GHC extensions may not be a popular opinion though. Am Mi., 27. Mai 2020 um 14:50 Uhr schrieb Carter Schonwald < carter.schonwald@gmail.com>:

...

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 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Carter Schonwald

3:41 p.m.

That’s actually a pretty concrete reason. As far as those go. That said, would be great to hear from more folks On Wed, May 27, 2020 at 11:26 AM Helmut Schmidt < helmut.schmidt.4711@gmail.com> wrote:

...

It's nice to verify that my code still works with GHC 7.0 which to my knowledge is the GHC version most compliant to the published Haskell 2010 Report. But I realize that nowadays making do with plain Haskell 2010 and without all those GHC extensions may not be a popular opinion though.

Am Mi., 27. Mai 2020 um 14:50 Uhr schrieb Carter Schonwald < carter.schonwald@gmail.com>:

...
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 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Alexey Kuleshevich

3:57 p.m.

Related question for those folks that still haven't moved to ghc-8. How do you guys write production code with such an old compiler? I am sure using older ghc itself is fine, but how can you rely on outdated libraries that contain bugs and security holes? A lot of the critical libraries do not even support ghc-7.10 (yaml, conduit, tls, resourcet, persistent, cryptonite, crypto-api, yesod, servant, etc.) while other support at most ghc-7.8 (network, aeson, unordered-containers ..) These are just a few libraries from the top downloaded list on Hackage. Also, Carter, you suggested recently that vector might drop support for ghc-7 as well: https://github.com/haskell/vector/issues/297#issuecomment-581601804 I personally rarely use ghc that is older than ghc-8.2, while most of the time I stay on a version that is just one major version short of the latest one that is released, simply because that is usually the latest stackage lts (eg. now it is lts-15, which is ghc-8.8.3) Alexey. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, May 27, 2020 6:25 PM, Helmut Schmidt wrote:

...

It's nice to verify that my code still works with GHC 7.0 which to my knowledge is the GHC version most compliant to the published Haskell 2010 Report. But I realize that nowadays making do with plain Haskell 2010 and without all those GHC extensions may not be a popular opinion though.

Am Mi., 27. Mai 2020 um 14:50 Uhr schrieb Carter Schonwald :

...
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 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

David Feuer

4:01 p.m.

Then there's the ST+multithreading bug in older versions that can produce wrong answers at random. On Wed, May 27, 2020, 11:58 AM Alexey Kuleshevich wrote:

...

Related question for those folks that still haven't moved to ghc-8. How do you guys write production code with such an old compiler? I am sure using older ghc itself is fine, but how can you rely on outdated libraries that contain bugs and security holes? A lot of the critical libraries do not even support ghc-7.10 (yaml, conduit, tls, resourcet, persistent, cryptonite, crypto-api, yesod, servant, etc.) while other support at most ghc-7.8 (network, aeson, unordered-containers ..) These are just a few libraries from the top downloaded list on Hackage. Also, Carter, you suggested recently that vector might drop support for ghc-7 as well: https://github.com/haskell/vector/issues/297#issuecomment-581601804

I personally rarely use ghc that is older than ghc-8.2, while most of the time I stay on a version that is just one major version short of the latest one that is released, simply because that is usually the latest stackage lts (eg. now it is lts-15, which is ghc-8.8.3)

Alexey.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, May 27, 2020 6:25 PM, Helmut Schmidt < helmut.schmidt.4711@gmail.com> wrote:

It's nice to verify that my code still works with GHC 7.0 which to my knowledge is the GHC version most compliant to the published Haskell 2010 Report. But I realize that nowadays making do with plain Haskell 2010 and without all those GHC extensions may not be a popular opinion though.

Am Mi., 27. Mai 2020 um 14:50 Uhr schrieb Carter Schonwald < carter.schonwald@gmail.com>:

...
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 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Henning Thielemann

4:06 p.m.

On Wed, 27 May 2020, Alexey Kuleshevich wrote:

...

Related question for those folks that still haven't moved to ghc-8. How do you guys write production code with such an old compiler? I am sure using older ghc itself is fine, but how can you rely on outdated libraries that contain bugs and security holes?

I do not rely on old libraries. I just do not use too new features and then my code works with new and old versions of those libraries. There are limitations of course.

Andreas Abel

5:55 p.m.

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 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Vanessa McHale

6:04 p.m.

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 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 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Carter Schonwald

8:08 p.m.

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 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 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.

...
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

...
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

...
Who are the users today and how important are they for todays library

On 2020-05-27 16:50, Carter Schonwald wrote: library. oldest supported / provided ghc. maintainers ?

...
_______________________________________________ Libraries mailing list 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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Andreas Abel

28 May 28 May

7:21 a.m.

@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

Callan McGill

1:16 p.m.

...

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

Carter Schonwald

4:33 p.m.

Very good point! On Thu, May 28, 2020 at 9:17 AM 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 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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Andreas Abel

4:40 p.m.

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

Malcolm Wallace

7:38 a.m.

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 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 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 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 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Libraries mailing list 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

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Carter Schonwald

12:19 p.m.

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 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 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 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 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.

...
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

...
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

...
Who are the users today and how important are they for todays library

On 2020-05-27 16:50, Carter Schonwald wrote: library. oldest supported / provided ghc. maintainers ?

...
_______________________________________________ Libraries mailing list 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

_______________________________________________ Libraries mailing list 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

1865

Age (days ago)

1867

Last active (days ago)

List overview

Download

30 comments

15 participants

participants (15)

Alexey Kuleshevich
amindfv＠gmail.com
Andreas Abel
Ben Gamari
Callan McGill
Carter Schonwald
David Feuer
Helmut Schmidt
Henning Thielemann
Joseph C. Sible
Malcolm Wallace
Richard Eisenberg
Sven Panne
Vanessa McHale
Zemyla

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

tags

participants (15)