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.
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
