"Only exceptionally would we fix a design flaw in a way that breaks
programs compiled with existing language editions."
https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/princi...
This is not exceptional is it? It's just a regular design flaw :) If we
must fix it, let's do it in a way that complies with the stability
principle.
Cheers
Simon
On Mon, 29 Jan 2024 at 11:15, Joachim Breitner
Hi,
Am Montag, dem 29.01.2024 um 11:03 +0000 schrieb Simon Marlow:
I might be a bit confused, but doesn't this proposal change the meaning of an existing extension (PatternSignatures)?
a long-ago deprecated one:
~ $ ghci GHCi, version 9.4.8: https://www.haskell.org/ghc/ :? for help ghci> :set -XPatternSignatures
<no location info>: warning: [-Wdeprecated-flags] -XPatternSignatures is deprecated: use -XScopedTypeVariables or pragma {-# LANGUAGE ScopedTypeVariables #-} instead
Hopefully our stability principles does not require us to heed programs that ignored deprecation flags for a while?
My understanding of
https://github.com/ghc-proposals/ghc-proposals/blob/wip/general-rules/princi... is that, despite “stable package” not saying “does not use features deprecated long ago”, it’s still ok to break such programs, as this is our mechanism GR3?
Of course we could side-step this procedural question about repurposing an old extension and introduce `SimplePatternSignatures` instead. Not in favor, simply because as a user I more than once intuitively reached for `PatternSignatures` to get the proposed behavior.
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee