On 15-10-22 09:29 AM, Geoffrey Mainland wrote:
...
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.
I have been fully in favour of all the proposals implemented so far, and I think that having an explicit master plan would be a great idea. It would address some of the process-related objections that have been raised, and it would provide a fixed long-term target that would be much easier to make the whole community aware of and contribute to. For that purpose, the master plan should be advertised directly on the front page of haskell.org. Once we have it settled and agreed, the purpose of the base-library commitee would essentially become to figure out the details like the timeline and code migration path. One thing they wouldn't need to worry about is whether anybody disagrees with their goals.
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!
From the discussions so far it appears that the answer for 3 years (or at least the next 3 GHC releases) would be to write the code that works with the current GHC and base, but this policy has not been codified anywhere yet. Knowing the upcoming changes doesn't help with making your code any more robust, and I think that's a shame. We could have a two-pronged policy: - code that works and compiles with the latest GHC with no *warnings* will continue to work and compile with no *errors* with the following 2 releases, and - code that also follows the forward-compatibility recommendations current for that version of GHC will continue to work and compile with no *errors* with the following 4 releases. The forward-compatibility recommendations would become a part of the online GHC documentation so nobody complains they didn't know about them. Personally, I'd prefer if the recommendations were built into the compiler itself as a new class of warnings, but then (a) some people would insist on turning them on together with -Werror and then complain when their builds break and (b) this would increase the pressure on GHC implementors.
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?
Because they have been investigated for years with no effect.
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.
I doubt we can, but this question has already been answered by others.