Re: Breaking Changes and Long Term Support Haskell
On 10/22/2015 11:02 AM, Matthias Hörmann wrote:
I would say that the need to import Control.Applicative in virtually every module manually definitely caused some pain before AMP.
In this particular case, there is a trade off between breaking code on the one hand and having to write some import statements on the other. I find writing some extra imports less painful than breaking (other people's and my) code, but the other position is defensible as well. I sense that I am in the minority, at least on the libraries list.
I would also argue that a non-negligible amount of effort goes into teaching the warts, the reasons for the warts and how to work around them.
Which wart(s) in particular? All of them? Does having return (and (>>)) in Monad make teaching more difficult? I teach Haskell beginners, and I found that AMP made explaining monads slightly more difficult because it served as a source of confusion for my students. On the other hand, the warts provide a teachable moment once students understand all this stuff :)
Dealing with AMP? I'm working on a collaborative research project that is stuck on 7.8 because of AMP. I am curious what exactly about AMP causes your research project to be "stuck" on GHC 7.8 considering we have had multiple people mention how little effort it took to update even large codebases. I think it would be useful information to have to plan future changes in a way that might avoid your issues.
I was hoping that mentioning this wouldn't distract from the three main (numbered) questions I posed below. Alas. If I were working alone, AMP wouldn't be a huge deal. I could fix the code for 7.10 compatibility, but then unless everyone switches to 7.10, changes to the codebase made by someone using 7.8, e.g., defining a new Monad instance, could break things on 7.10 again. It's easier to stick with 7.8. Any time spent dealing with compatibility issues is time not spent writing actual code. I outlined one possible path to avoid this kind of issue: spend more time thinking about ways to maintain compatibility. We had proposals for doing this with AMP. Cheers, Geoff
On Thu, Oct 22, 2015 at 3:29 PM, Geoffrey Mainland <mainland@apeiron.net> wrote:
On 10/22/2015 02:40 AM, Edward Kmett wrote:
On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins <greg@gregorycollins.net <mailto:greg@gregorycollins.net>> wrote:
On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland <mainland@apeiron.net <mailto:mainland@apeiron.net>> wrote:
My original email stated my underlying concern: we are losing valuable members of the community not because of the technical decisions that are being made, but because of the process by which they are being made.
[If] you're doing research you're on the treadmill, almost by definition, and you're delighted that we're finally making some rapid progress on fixing up some of the longstanding warts.
If you're a practitioner, you are interested in using Haskell for, y'know, writing programs. You're probably in one of two camps: you're in "green field" mode writing a lot of new code (early stage startups, prototype work, etc), or you're maintaining/extending programs you've already written that are out "in the field" for you doing useful work. Laura Wingerd calls this the "annealing temperature" of software, and I think this is a nice metaphor to describe it. How tolerant you are of ecosystem churn depends on what your temperature is: and I think it should be obvious to everyone that Haskell having "success" for programming work would mean that lots of useful and correct programs get written, so everyone who is in the former camp will cool over time to join the latter.
I've made the point before and I don't really want to belabor it: our de facto collective posture towards breaking stuff, especially in the past few years, has been extremely permissive, and this alienates people who are maintaining working programs.
Even among people who purported to be teaching Haskell or using Haskell today in industry the margin of preference for the concrete FTP proposal was ~79%. This was considerably higher than I expected in two senses. One: there were a lot more people who claimed to be in one of those two roles than I expected by far, and two: their appetite for change was higher than I expected. I initially expected to see a stronger "academic vs. industry" split in the poll, but the groups were only distinguishable by a few percentage point delta, so while I expected roughly the end percentage of the poll, based on the year prior I'd spent running around the planet to user group meetings and the like, I expected it mostly because I expected more hobbyists and less support among industrialists.
I'm actually firmly of the belief that the existing committee doesn't really have process issues, and in fact, that often it's been pretty careful to minimize the impact of the changes it wants to make. As others have pointed out, lots of the churn actually comes from platform libraries, which are out of the purview of this group.
Historically we've had a bit of a split personality on this front. Nothing that touches the Prelude had changed in 17 years. On the other hand the platform libraries had maintained a pretty heavy rolling wave of breakage the entire time I've been around in the community. On a more experimental feature front, I've lost count of the number of different things we've done to Typeable or template-haskell.
All I'm saying is that if we want to appeal to or cater to working software engineers, we have to be a lot less cavalier about causing more work for them, and we need to prize stability of the core infrastructure more highly. That'd be a broader cultural change, and that goes beyond process: it's policy.
The way things are shaping up, we've had 17 years of rock solid stability, 1 release that incorporated changes that were designed to minimize impact, to the point that the majority of the objections against them are of the form where people would prefer that we broke _more_ code, to get a more sensible state. Going forward, it looks like the next 2 GHC releases will have basically nothing affecting the Prelude, and there will be another punctuation in the equilibrium around 8.4 as the next set of changes kicks in over 8.4 and 8.6 That gives 2 years worth of advance notice of pending changes, and a pretty strong guarantee from the committee that you should be able to maintain code with a 3 release window without running afoul of warnings or needing CPP.
So, out of curiosity, what additional stability policy is it that you seek? Thanks to you and Dan [1], I now have a greater understanding and appreciation for where the committee has been coming from. My new understanding is that the changes that were formalized in AMP, FTP, and MRP were the basis for the committee's creation. It also seems that there are more changes in the pipeline that have not yet been made into proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of "stability" is signaling change as far ahead as possible. The committee has put a lot of effort into this, which I appreciate! However, as each of these proposal has come down the pipeline, I never realized that they were part of a larger master plan.
1) What is the master plan, and where is it documented, even if this document is not up to the standard of a proposal? What is the final target, and when might we expect it to be reached? What is in the pipeline after MRP?
Relatedly, guidance on how to write code now so that it will be compatible with future changes helps mitigate the stability issue.
2) How can I write code that makes use of the Prelude so that it will work with every new GHC release over the next 3 years? 5 years? For example, how can I write a Monad instance now, knowing the changes that are coming, so that the instance will work with every new GHC release for the next 3 years? 5 years? If the answer is "you can't," then when might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to say I don't know the answer!
Finally, if none of these changes broke Prelude backwards compatibility, far fewer people would be complaining :) Of course, we can't always make progress without breaking things, but a more deliberative process might offer an opportunity to make progress while still preserving backwards compatibility. Take AMP for example. There were at least two [3] [4] proposals for preserving backwards compatibility. Investigating them would have taken time and delayed AMP, yes, but why the rush?
3) Can we have a process that allows more deliberation over, and wider publicity for, changes that break backwards compatibility? The goal of such a process would not be to prevent change, but to allow more time to find possible solution to the issue of backwards compatibility.
My proposal for a low-traffic mailing list where all proposals were announced was meant to provide wider publicity.
Personally, I think these proposals do indeed fix a lot of warts in the language. As a researcher who uses actively uses Haskell every day, these warts have had approximately zero impact on me for the past (almost) decade, and I would be perfectly content if they were never fixed. The only pain I can recall enduring is having to occasionally write an orphan Applicative instance. I have been importing Prelude hiding mapM for years. I have been importing Control.Applicative for years. Neither has been painful. Dealing with AMP? I'm working on a collaborative research project that is stuck on 7.8 because of AMP. I agree, that seems silly, but whether or not it is silly, it is an impact I feel.
One way to look at these proposals is to ask the question "Wouldn't the language be nicer if all these changes were made?" Another is to ask the question "Does the fact that these changes have not been made make your life as a Haskell programmer more difficult in any significant way?" I answer "yes" to the former and "no" to the latter. Is our stance that answering "yes" to the former question is enough to motivate braking change? Shouldn't a answer "no" to the latter question cause some hesitation?
Maybe there are a lot of people who answer "yes" to both questions. I would like to know! But does having return in the Monad class really cause anyone anything other than existential pain?
Cheers, Geoff
[1] https://mail.haskell.org/pipermail/libraries/2015-October/026390.html [2] https://mail.haskell.org/pipermail/libraries/2015-September/026158.html [3] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates [4] https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses
On Thu, Oct 22, 2015 at 11:36 AM, Geoffrey Mainland <mainland@apeiron.net> wrote:
On 10/22/2015 11:02 AM, Matthias Hörmann wrote:
I would say that the need to import Control.Applicative in virtually every module manually definitely caused some pain before AMP.
In this particular case, there is a trade off between breaking code on the one hand and having to write some import statements on the other. I find writing some extra imports less painful than breaking (other people's and my) code, but the other position is defensible as well. I sense that I am in the minority, at least on the libraries list.
I would also argue that a non-negligible amount of effort goes into teaching the warts, the reasons for the warts and how to work around them.
Which wart(s) in particular? All of them? Does having return (and (>>)) in Monad make teaching more difficult?
Having (>>) means that we have hundreds of monads out there where (>>) has been optimized, but (*>) has not. If I were working alone, AMP wouldn't be a huge deal. I could fix the
code for 7.10 compatibility, but then unless everyone switches to 7.10, changes to the codebase made by someone using 7.8, e.g., defining a new Monad instance, could break things on 7.10 again. It's easier to stick with 7.8. Any time spent dealing with compatibility issues is time not spent writing actual code.
In the open source world many of us just fire off our code to travis-ci and get it to build with a dozen different compiler versions. I maintain a lot of code that supports things back to 7.0 and forward to HEAD this way.
I outlined one possible path to avoid this kind of issue: spend more time thinking about ways to maintain compatibility. We had proposals for doing this with AMP.
And on the other hand we also had a concrete proposal that didn't require language changes that was ridiculously popular. People had been talking about Applicative as a superclass of Monad for a decade before we finally acted upon the AMP. People had been talking about superclass defaulting for a decade. When do you cut off discussion and ship the proposal that has overwhelming support? If there is no process that enables this you can stall the process indefinitely by raising objections of this form. Such a situation is not without costs all its own. -Edward
Cheers, Geoff
On Thu, Oct 22, 2015 at 3:29 PM, Geoffrey Mainland <mainland@apeiron.net>
wrote:
On 10/22/2015 02:40 AM, Edward Kmett wrote:
On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins <greg@gregorycollins.net <mailto:greg@gregorycollins.net>> wrote:
On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland <mainland@apeiron.net <mailto:mainland@apeiron.net>> wrote:
My original email stated my underlying concern: we are losing valuable members of the community not because of the technical decisions that are being made, but because of the process by which they are being made.
[If] you're doing research you're on the treadmill, almost by definition, and you're delighted that we're finally making some rapid progress on fixing up some of the longstanding warts.
If you're a practitioner, you are interested in using Haskell for, y'know, writing programs. You're probably in one of two camps: you're in "green field" mode writing a lot of new code (early stage startups, prototype work, etc), or you're maintaining/extending programs you've already written that are out "in the field" for you doing useful work. Laura Wingerd calls this the "annealing temperature" of software, and I think this is a nice metaphor to describe it. How tolerant you are of ecosystem churn depends on what your temperature is: and I think it should be obvious to everyone that Haskell having "success" for programming work would mean that lots of useful and correct programs get written, so everyone who is in the former camp will cool over time to join the latter.
I've made the point before and I don't really want to belabor it: our de facto collective posture towards breaking stuff, especially in the past few years, has been extremely permissive, and this alienates people who are maintaining working programs.
Even among people who purported to be teaching Haskell or using Haskell today in industry the margin of preference for the concrete FTP proposal was ~79%. This was considerably higher than I expected in two senses. One: there were a lot more people who claimed to be in one of those two roles than I expected by far, and two: their appetite for change was higher than I expected. I initially expected to see a stronger "academic vs. industry" split in the poll, but the groups were only distinguishable by a few percentage point delta, so while I expected roughly the end percentage of the poll, based on the year prior I'd spent running around the planet to user group meetings and the like, I expected it mostly because I expected more hobbyists and less support among industrialists.
I'm actually firmly of the belief that the existing committee doesn't really have process issues, and in fact, that often it's been pretty careful to minimize the impact of the changes it wants to make. As others have pointed out, lots of the churn actually comes from platform libraries, which are out of the purview of this group.
Historically we've had a bit of a split personality on this front. Nothing that touches the Prelude had changed in 17 years. On the other hand the platform libraries had maintained a pretty heavy rolling wave of breakage the entire time I've been around in the community. On a more experimental feature front, I've lost count of the number of different things we've done to Typeable or template-haskell.
All I'm saying is that if we want to appeal to or cater to working software engineers, we have to be a lot less cavalier about causing more work for them, and we need to prize stability of the core infrastructure more highly. That'd be a broader cultural change, and that goes beyond process: it's policy.
The way things are shaping up, we've had 17 years of rock solid stability, 1 release that incorporated changes that were designed to minimize impact, to the point that the majority of the objections against them are of the form where people would prefer that we broke _more_ code, to get a more sensible state. Going forward, it looks like the next 2 GHC releases will have basically nothing affecting the Prelude, and there will be another punctuation in the equilibrium around 8.4 as the next set of changes kicks in over 8.4 and 8.6 That gives 2 years worth of advance notice of pending changes, and a pretty strong guarantee from the committee that you should be able to maintain code with a 3 release window without running afoul of warnings or needing CPP.
So, out of curiosity, what additional stability policy is it that you seek? Thanks to you and Dan [1], I now have a greater understanding and appreciation for where the committee has been coming from. My new understanding is that the changes that were formalized in AMP, FTP, and MRP were the basis for the committee's creation. It also seems that there are more changes in the pipeline that have not yet been made into proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of "stability" is signaling change as far ahead as possible. The committee has put a lot of effort into this, which I appreciate! However, as each of these proposal has come down the pipeline, I never realized that they were part of a larger master plan.
1) What is the master plan, and where is it documented, even if this document is not up to the standard of a proposal? What is the final target, and when might we expect it to be reached? What is in the pipeline after MRP?
Relatedly, guidance on how to write code now so that it will be compatible with future changes helps mitigate the stability issue.
2) How can I write code that makes use of the Prelude so that it will work with every new GHC release over the next 3 years? 5 years? For example, how can I write a Monad instance now, knowing the changes that are coming, so that the instance will work with every new GHC release for the next 3 years? 5 years? If the answer is "you can't," then when might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to say I don't know the answer!
Finally, if none of these changes broke Prelude backwards compatibility, far fewer people would be complaining :) Of course, we can't always make progress without breaking things, but a more deliberative process might offer an opportunity to make progress while still preserving backwards compatibility. Take AMP for example. There were at least two [3] [4] proposals for preserving backwards compatibility. Investigating them would have taken time and delayed AMP, yes, but why the rush?
3) Can we have a process that allows more deliberation over, and wider publicity for, changes that break backwards compatibility? The goal of such a process would not be to prevent change, but to allow more time to find possible solution to the issue of backwards compatibility.
My proposal for a low-traffic mailing list where all proposals were announced was meant to provide wider publicity.
Personally, I think these proposals do indeed fix a lot of warts in the language. As a researcher who uses actively uses Haskell every day, these warts have had approximately zero impact on me for the past (almost) decade, and I would be perfectly content if they were never fixed. The only pain I can recall enduring is having to occasionally write an orphan Applicative instance. I have been importing Prelude hiding mapM for years. I have been importing Control.Applicative for years. Neither has been painful. Dealing with AMP? I'm working on a collaborative research project that is stuck on 7.8 because of AMP. I agree, that seems silly, but whether or not it is silly, it is an impact I feel.
One way to look at these proposals is to ask the question "Wouldn't the language be nicer if all these changes were made?" Another is to ask the question "Does the fact that these changes have not been made make your life as a Haskell programmer more difficult in any significant way?" I answer "yes" to the former and "no" to the latter. Is our stance that answering "yes" to the former question is enough to motivate braking change? Shouldn't a answer "no" to the latter question cause some hesitation?
Maybe there are a lot of people who answer "yes" to both questions. I would like to know! But does having return in the Monad class really cause anyone anything other than existential pain?
Cheers, Geoff
[1] https://mail.haskell.org/pipermail/libraries/2015-October/026390.html [2] https://mail.haskell.org/pipermail/libraries/2015-September/026158.html [3] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates [4] https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
I outlined one possible path to avoid this kind of issue: spend more time thinking about ways to maintain compatibility. We had proposals for doing this with AMP.
And on the other hand we also had a concrete proposal that didn't require language changes that was ridiculously popular. People had been talking about Applicative as a superclass of Monad for a decade before we finally acted upon the AMP. People had been talking about superclass defaulting for a decade. When do you cut off discussion and ship the proposal that has overwhelming support? If there is no process that enables this you can stall the process indefinitely by raising objections of this form. Such a situation is not without costs all its own.
I agree. It was certainly within the power of the committee to start a clock and say something like "if we don't have a patch to GHC that provides backwards compatibility for AMP within 1 year, we will push out AMP as-is." Had I understand the implications of AMP at the time, or even been aware that AMP was happening (I was actually actively working on the GHC code base during that period), that certainly would have been motivation for me to do something about it! *That* would be how one could cut off discussion and ship a proposal. I am not against changing the Prelude! But it sure would be nice if -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a Haskell 2010 Prelude, both of which could be used with external packages that themselves used the more modern Prelude. Maybe that's impossible. Setting a firm deadline to finding a solution to the compatibility issue would have been a way to compromise. Ideally, changing the Prelude wouldn't require breaking code written to use an older version of the Prelude. Yes, attaining that goal would require more work. Evolving the Prelude and maintaining compatibility are not necessarily mutually exclusive options. Cheers, Geoff
On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland <mainland@apeiron.net> wrote:
I outlined one possible path to avoid this kind of issue: spend more time thinking about ways to maintain compatibility. We had proposals for doing this with AMP.
And on the other hand we also had a concrete proposal that didn't require language changes that was ridiculously popular. People had been talking about Applicative as a superclass of Monad for a decade before we finally acted upon the AMP. People had been talking about superclass defaulting for a decade. When do you cut off discussion and ship the proposal that has overwhelming support? If there is no process that enables this you can stall the process indefinitely by raising objections of this form. Such a situation is not without costs all its own.
I agree. It was certainly within the power of the committee to start a clock and say something like "if we don't have a patch to GHC that provides backwards compatibility for AMP within 1 year, we will push out AMP as-is." Had I understand the implications of AMP at the time, or even been aware that AMP was happening (I was actually actively working on the GHC code base during that period), that certainly would have been motivation for me to do something about it! *That* would be how one could cut off discussion and ship a proposal.
I freely admit that there is room for improvement in the process. We're all learning here. The current Semigroup-Monoid proposal more or less fits the bill you are looking for here. We have a roadmap today that migrates an existing package with several years worth of back support into base more or less unmodified, and then in 3 releases starts requiring instances. You can think of that 3 release clock as precisely what you are looking for here. If we get an implementation of superclass defaulting or some other mechanism that can mitigate the extra couple of lines of code that this proposal will tax users with, within that timeline, we'd gladly incorporate it into the proposal.
I am not against changing the Prelude! But it sure would be nice if -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a Haskell 2010 Prelude, both of which could be used with external packages that themselves used the more modern Prelude.
It would definitely be a preferable state of affairs. Unfortunately, at least with the tools available to us today, such a plan is incompatible with any plan that introduces a new superclass. It also cuts off plans that ever factors an existing class into two, such as the MonadFail proposals. We simply do not at this time have the technical capabilities that would support such a system. If they showed up in GHC we can adapt plans to fit.
Maybe that's impossible. Setting a firm deadline to finding a solution to the compatibility issue would have been a way to compromise. Ideally, changing the Prelude wouldn't require breaking code written to use an older version of the Prelude. Yes, attaining that goal would require more work.
We looked around for a year for a roadmap that would get us there. None presented itself. In the end we wound up shedding the core libraries status of the haskell98 and haskell2010 packages as the 3-4 different ways in which one could write a Haskell2010 package all have different trade-offs and can be maintained in user-land. Examples: * A hardline version of haskell2010 with a Monad and Num that fully complies with the report, but which doesn't work with Monad and Num instances supplied by other libraries. This needs RebindableSyntax, so it doesn't quite work right. With compiler support for rebinding syntax to a particular library instead of to whatever is in scope, such a thing might be suitable for teaching a Haskell class. * A pragmatic haskell2010 where the Monad has an Applicative superclass and Num has the current semantic. This works with everything but doesn't faithfully follow the report. * A middle-ground package that tries to use a superclass defaulting mechanism that we don't have to supply missing Applicative superclasses might resolve the Applicative-Monad issue in theory, but does nothing for report compliance of our existing Num. Each one of these solutions has flaws. Two of them require innovations in the compiler that we don't have.
Evolving the Prelude and maintaining compatibility are not necessarily mutually exclusive options.
Agreed, but as you can see above, maintaining compatibility isn't necessarily always a viable option either. -Edward
On 10/22/2015 01:29 PM, Edward Kmett wrote:
On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland <mainland@apeiron.net <mailto:mainland@apeiron.net>> wrote:
I am not against changing the Prelude! But it sure would be nice if -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a Haskell 2010 Prelude, both of which could be used with external packages that themselves used the more modern Prelude.
It would definitely be a preferable state of affairs. Unfortunately, at least with the tools available to us today, such a plan is incompatible with any plan that introduces a new superclass. It also cuts off plans that ever factors an existing class into two, such as the MonadFail proposals. We simply do not at this time have the technical capabilities that would support such a system. If they showed up in GHC we can adapt plans to fit.
Great! Could we work to characterize what technical capabilities we would need to support full backwards Prelude compatibility? Here is my rough understanding of what we would need: 1) Some method for "default superclasses." This would solve the AMP issue. 2) A method for factoring existing classes into two (or more) parts. This would solve the MonadFail problem. 3) A method for imposing extra superclass constraints on a class. This would be needed for full Num compatibility. Seems much less important that 1 and 2. The most thought has gone into 1. Are these three technical capabilities *all* that we would need? Perhaps we also need a way to tie the current language (-XHaskell98, -XHaskell2010) to a particular implementation of the Prelude. Geoff
On 10/22/2015 07:41 PM, Geoffrey Mainland wrote:
On 10/22/2015 01:29 PM, Edward Kmett wrote:
On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland <mainland@apeiron.net <mailto:mainland@apeiron.net>> wrote:
I am not against changing the Prelude! But it sure would be nice if -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a Haskell 2010 Prelude, both of which could be used with external packages that themselves used the more modern Prelude.
It would definitely be a preferable state of affairs. Unfortunately, at least with the tools available to us today, such a plan is incompatible with any plan that introduces a new superclass. It also cuts off plans that ever factors an existing class into two, such as the MonadFail proposals. We simply do not at this time have the technical capabilities that would support such a system. If they showed up in GHC we can adapt plans to fit.
Great!
Could we work to characterize what technical capabilities we would need to support full backwards Prelude compatibility?
It's basically the stuff that never materialized in 10 years until people got fed up with the situation and voted AMP through even though it would cause (limited) breakage.
Here is my rough understanding of what we would need:
1) Some method for "default superclasses." This would solve the AMP issue.
2) A method for factoring existing classes into two (or more) parts. This would solve the MonadFail problem.
3) A method for imposing extra superclass constraints on a class. This would be needed for full Num compatibility. Seems much less important that 1 and 2.
The most thought has gone into 1.
Are these three technical capabilities *all* that we would need? Perhaps we also need a way to tie the current language (-XHaskell98, -XHaskell2010) to a particular implementation of the Prelude.
You say "all" as if a) it's easy (hint: it's all highly non-trivial), b) anybody's actually going to do the work. Look, we'd all like unicorns and rainbows, but clearly nobody's done the required work[1], and a lot of people were getting fed up with the status quo. Just wishing that this will happen won't make it so, and frankly, downplaying the difficulty seems like an attempt to veto any change. Regards, [1] Understandable, given the highly non-trivial nature of it.
On Thu, Oct 22, 2015 at 1:41 PM, Geoffrey Mainland <mainland@apeiron.net> wrote:
On 10/22/2015 01:29 PM, Edward Kmett wrote:
On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland <mainland@apeiron.net <mailto:mainland@apeiron.net>> wrote:
I am not against changing the Prelude! But it sure would be nice if -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a Haskell 2010 Prelude, both of which could be used with external packages that themselves used the more modern Prelude.
It would definitely be a preferable state of affairs. Unfortunately, at least with the tools available to us today, such a plan is incompatible with any plan that introduces a new superclass. It also cuts off plans that ever factors an existing class into two, such as the MonadFail proposals. We simply do not at this time have the technical capabilities that would support such a system. If they showed up in GHC we can adapt plans to fit.
Great!
Could we work to characterize what technical capabilities we would need to support full backwards Prelude compatibility?
Here is my rough understanding of what we would need:
1) Some method for "default superclasses." This would solve the AMP issue.
2) A method for factoring existing classes into two (or more) parts. This would solve the MonadFail problem.
3) A method for imposing extra superclass constraints on a class. This would be needed for full Num compatibility. Seems much less important that 1 and 2.
The most thought has gone into 1.
Are these three technical capabilities *all* that we would need? Perhaps we also need a way to tie the current language (-XHaskell98, -XHaskell2010) to a particular implementation of the Prelude.
I don't have a concrete plan here. I'm not even sure one can be achieved that works. I'd say that the burden of figuring out such a thing falls on the party that can create a plan, pitch it to the community and potentially implement it. If I enumerate a set of conditions here I'm basically implying that I'd agree to any plan that incorporated them. I'm just not prepared to make that commitment sight-unseen to something with unknown warts and implications. I can, however, say that it is plausible that what you have enumerated above could potentially address the outstanding issues, but I don't know how good of a compromise the result would be. -Edward
On 10/22/2015 02:25 PM, Edward Kmett wrote:
On Thu, Oct 22, 2015 at 1:41 PM, Geoffrey Mainland <mainland@apeiron.net <mailto:mainland@apeiron.net>> wrote:
On 10/22/2015 01:29 PM, Edward Kmett wrote: > On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland > <mainland@apeiron.net <mailto:mainland@apeiron.net> <mailto:mainland@apeiron.net <mailto:mainland@apeiron.net>>> wrote: > > > I am not against changing the Prelude! But it sure would be nice if > -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a > Haskell 2010 Prelude, both of which could be used with external > packages > that themselves used the more modern Prelude. > > > It would definitely be a preferable state of affairs. Unfortunately, > at least with the tools available to us today, such a plan is > incompatible with any plan that introduces a new superclass. It also > cuts off plans that ever factors an existing class into two, such as > the MonadFail proposals. We simply do not at this time have the > technical capabilities that would support such a system. If they > showed up in GHC we can adapt plans to fit.
Great!
Could we work to characterize what technical capabilities we would need to support full backwards Prelude compatibility?
Here is my rough understanding of what we would need:
1) Some method for "default superclasses." This would solve the AMP issue.
2) A method for factoring existing classes into two (or more) parts. This would solve the MonadFail problem.
3) A method for imposing extra superclass constraints on a class. This would be needed for full Num compatibility. Seems much less important that 1 and 2.
The most thought has gone into 1.
Are these three technical capabilities *all* that we would need? Perhaps we also need a way to tie the current language (-XHaskell98, -XHaskell2010) to a particular implementation of the Prelude.
I don't have a concrete plan here. I'm not even sure one can be achieved that works. I'd say that the burden of figuring out such a thing falls on the party that can create a plan, pitch it to the community and potentially implement it.
If I enumerate a set of conditions here I'm basically implying that I'd agree to any plan that incorporated them. I'm just not prepared to make that commitment sight-unseen to something with unknown warts and implications.
I can, however, say that it is plausible that what you have enumerated above could potentially address the outstanding issues, but I don't know how good of a compromise the result would be.
-Edward
I don't have a concrete plan either, not am I sure that one is possible. But I don't see how having a conversation about how one might achieve backwards compatibility would commit anyone to anything. Any eventual proposal would have to go through the same approval process as every other proposal. And even if we did have a hypothetical draft proposal that you had at some point stated you approved of in some way, you would always be free to change your mind! Isn't the libraries list exactly where this sort of conversation should happen? Cheers, Geoff
| > Are these three technical capabilities *all* that we would need? | > Perhaps | > we also need a way to tie the current language (-XHaskell98, | > -XHaskell2010) to a particular implementation of the Prelude. | > | > | > I don't have a concrete plan here. I'm not even sure one can be | > achieved that works. I'd say that the burden of figuring out such a | > thing falls on the party that can create a plan, pitch it to the | > community and potentially implement it. In fact there is more than one concrete plan: https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses All are complex, only partially designed, entirely unimplemented (and the implementation will be non-trivial), and lacking an active champion. The one I link to above is probably the leading contender, but it feels too complicated to me. Simon
participants (4)
-
Bardur Arantsson -
Edward Kmett -
Geoffrey Mainland -
Simon Peyton Jones