Re: [ghc-steering-committee] #632: Phased introduction of GHC2024

On Fri, 22 Mar 2024 at 18:27, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

I really want ghci to use the latest and greatest language edition.

I think we agree about this

I also would prefer it to be used when calling ghc on a quick test file. If deemed necessary we can throw a warning when we fallback to a default in that case.

Ah, but now we are on the slippery slope. Your "quick test file" may well become a little script you use every day... and it may then suddenly stop working when you install a new GHC with a new default language edition. We don't want that! And it is completely solved by saying that we never change the default language edition for .hs modules -- if it works now it'll work in the future because we always fall back to the same language edition. (e.g Hsakell98 or GHC2021 or whatever).

In some ways Hakell98 is better: it's very stable; and it is so old that it'll encourage you to put a one-line {-# LANGUAGE GHC2024 #-} at the top of your module to make it self-describing. I love self-describing files :-)

I can think of a couple of reasons not to fix the default language permanently: - Eventually we'll want to remove support for Haskell98, GHC2021 etc. because supporting old versions of the language gets harder over time. The Fortified Language Editions proposal requires 3 years of support only. (indeed Haskell98 is already not really Haskell98, because the definition of Monad has changed for example) - Other languages don't do it this way, e.g. with gcc/g++ you get some recent version of C/C++ by default. Cheers Simon

I wonder if this debate would be better on the GitHub discussion thread? I'd love to hear from more people.

Simon

On Fri, 22 Mar 2024 at 14:42, Malte Ott wrote:

...

I also think that the notion of default-language matters. For some reason people care greatly about which is the "real" Haskell.

I really want ghci to use the latest and greatest language edition. I also would prefer it to be used when calling ghc on a quick test file. If deemed necessary we can throw a warning when we fallback to a default in that case.

I think it is very important that we care about breakage for the sake of the ecosystem. But the ecosystem relies on Cabal to build packages so outside of that changes have another quality.

Best Malte _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee