If we converge, we'll turn that into a proper PR for the GHC proposal process, although it has wider implications than just GHC proposals and we should share with a broader audience. But let's start with the steering committee.
Any views? You all have edit rights.
I think that the draft covers Moritz's and Julian's goals, at least that was my intention. I have pasted Moritz's last email below, for context.
Now, this is derailing the original discussion a bit, and I'm not sure how far we want to take this. But, regarding
@Simon Marlow's comment
This is one cultural aspect of our community I'd like to shift: the
expectation that it's OK to make breaking changes as long as you warn about
them or go through a migration cycle. It just isn't! (and I speak as
someone who used to make lots of changes, I'm now fully repentant!). That's
not to say that we shouldn't ever change anything, but when considering the
cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it
just defers it.
I actually read this as we should stop having breaking changes to begin with. And _if_ we
do have breaking changes, that deprecation does not change the need to actually change
"smears" the cost. The--to me--_much_ bigger implication of deprecation cycles is that we
_inform_ our _customers_ about upcoming changes _early_, instead of _after the fact_. We
also give them ample time to react. Being by changing their code, or raising their concerns.
Would the Simplified Subsumptions / Deep Subsumptions change have looked differently?
As such I see deprecation cycles as orthogonal to the question if we should have breaking
changes to begin with.
Thus I believe the following:
- Do have a deprecation cycle if possible.
- Do not treat a deprecation cycle as an excuse. Costs are deferred but are as large as ever.
should be upgraded to:
- Preferably _no_ breaking changes.
- If breaking changes, then with a deprecation cycle, unless technically infeasible.
- An understanding that any breaking change incurs significant costs.
Ocaml recently added multicore support, and they put tremendous effort into making
PS:
we should also agree that a "stable" extension should not require
dependencies on ghc-experimental. To become stable, any library support
for an extension must move into `base`.
This
seems like a good idea, however I still remain that _experimental_
features should not be on-by-default in a stable compiler. Yes, ideally
I'd not even see them in a stable compiler, but I know this view is
contentious. The use of `ghc-experimental` should therefore be guarded
by `--std=experimental` as Julian suggested. That is a loud opt-in to
experimental features.