What Haskell users are actively maintaining or deving software using ghc <8
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 ?
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.
On Wed, May 27, 2020 at 11:09 AM Henning Thielemann <lemming@henning-thielemann.de> 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
El 27 may 2020, a las 16:33, Joseph C. Sible <josephcsible@gmail.com> escribió:
On Wed, May 27, 2020 at 11:09 AM Henning Thielemann <lemming@henning-thielemann.de> 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
On Wed, 27 May 2020, Joseph C. Sible wrote:
On Wed, May 27, 2020 at 11:09 AM Henning Thielemann <lemming@henning-thielemann.de> 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)".
On Wed, May 27, 2020 at 5:27 PM Henning Thielemann <lemming@henning-thielemann.de> 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
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) ?
El 27 may 2020, a las 18:19, Joseph C. Sible <josephcsible@gmail.com> escribió:
On Wed, May 27, 2020 at 5:27 PM Henning Thielemann <lemming@henning-thielemann.de> 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)
Henning Thielemann <lemming@henning-thielemann.de> writes:
On Wed, 27 May 2020, Joseph C. Sible wrote:
On Wed, May 27, 2020 at 11:09 AM Henning Thielemann <lemming@henning-thielemann.de> 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
On Thu, 28 May 2020, Ben Gamari wrote:
Henning Thielemann <lemming@henning-thielemann.de> 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.
Henning Thielemann <lemming@henning-thielemann.de> writes:
On Thu, 28 May 2020, Ben Gamari wrote:
Henning Thielemann <lemming@henning-thielemann.de> 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.
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
On May 29, 2020, at 4:47 AM, Ben Gamari <ben@smart-cactus.org> wrote:
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
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 <rae@richarde.dev> wrote:
On May 29, 2020, at 4:47 AM, Ben Gamari <ben@smart-cactus.org> wrote:
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
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.
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.
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 <lemming@henning-thielemann.de <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
Am Fr., 29. Mai 2020 um 16:35 Uhr schrieb Zemyla <zemyla@gmail.com>:
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.
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
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
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
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 <alexey@kuleshevi.ch> 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
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.
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
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@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 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
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@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@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 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: 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@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 <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> >> 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
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@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@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 <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> >> 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
Very good point! On Thu, May 28, 2020 at 9:17 AM Callan McGill <callan.mcgill@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@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@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 <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> >> 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
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@ifi.lmu.de <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 <vamchale@gmail.com <mailto:vamchale@gmail.com> > <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 > <andreas.abel@ifi.lmu.de <mailto:andreas.abel@ifi.lmu.de> <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 <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 <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 <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
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 <carter.schonwald@gmail.com> 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@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@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 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
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 <malcolm.wallace@me.com> 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 <carter.schonwald@gmail.com> 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@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@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 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
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