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 <malte.ott@maralorn.de> 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