Just to clarify: I am not against change, or evolution. I'm actually
looking forward to progress. What I am against ist sudden breakage.
As such, if there _is_ breakage (clc stackage is a subset), we have to
assume there will be breakage in production codebases, most
of which are likely not public.
Can't we have `-Wcompat` enable `-Werror=missing-methods`, and
`-Werror=missing-fields` (I guess that's the same as `-Werror=sever`?)
Advertise this prominently in the release notes for GHC 9.10? And then
enable this fully in GHC 9.14? Though I guess the flag we want
is really `-Wcompat-error`, or we rather change the notion of -Wcompat to
also promote warnings to errors early? In any case either the
current documentation for -Wcompat would need to be adjusted, or we'd need
something that signals new errors.
Ideally I'd like to see something like a warning for `missing-methods`,
with an additional note that this will become an error in GHC X.Y,
and that one can opt into this behaviour by enabling -Wcompat.
My test for support is generally: can I take existing code unmodified, swap
out the compiler, and it will still compile? That way I can report
back regressions, bugs, ... early on during alphas, betas, and release
candidates. Right now I can't. I usually have to wait for x.y.4+. That
also means the feedback for anyone working on GHC is terrible. You won't
hear about bugs until late in the release cycle where the
master branch has moved forward by a lot. At the same time it's painful for
integrators who end up having to backport and patch old
branches. https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status already
states anything but 9.4 and 9.6 won't see any further releases.
Our current production compiler is 8.10, we could not switch to 9.2 due to
performance regressions. And finally have almost everything
compiling with 9.6, but are far from having any form of performance profile
feedback on 9.6 yet.
Again, I'm not against breakage per-se. I'm against sudden breakage.
Managed evolution or however we want to call it, is something
I'd absolutely support!
Best,
Moritz
On Tue, 19 Sept 2023 at 15:15, Adam Gundry
On 18/09/2023 20:28, Richard Eisenberg wrote:
Bottom line for me: I think we should implement and then experiment. Given the potentially delicate nature of this, I might even advocate for implementing this in a release branch, so that as much of Hackage as possible actually has a hope of compiling. Then test to see where the breakage occurs. If were happy with the result, rebase the implementation on master. But I don't want us to get into a state where we accept, implement, observe moderate breakage, and then blast ahead because the committee approved the idea.
The breakage concern is worth thinking about, I agree, but fortunately in this instance we don't need to wait for an implementation to run an experiment. The change can be relatively effectively simulated by compiling with -Werror=missing-methods -Werror=missing-fields, and indeed Oleg has done so already for clc-stackage as he reports here:
https://github.com/ghc-proposals/ghc-proposals/issues/544#issue-1410125536
https://github.com/ghc-proposals/ghc-proposals/issues/544#issuecomment-12799...
Out of nearly 3000 packages, he found 22 were broken by -Werror=missing-methods and 9 by -Werror=missing-fields.
Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee