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

[Adam Gundry]

I posted a summary of options to the GitHub thread to try to solicit 
further feedback 
(https://github.com/ghc-proposals/ghc-proposals/pull/632#issuecomment-2021426391).

One idea I noticed rereading the thread was Gershom's suggestion 
(https://github.com/ghc-proposals/ghc-proposals/pull/632#issuecomment-1924318071) 
that we could change the default language when the compiler gets a 
supermajor version bump. We missed that by a release last time, as GHC 
9.0 used Haskell2010 but 9.2 used GHC2021. But we could plan for the 
next release after GHC 9.10 to be 10.0 and use GHC2024 by default, then 
in three years release GHC 11.0 with GHC2027...

Adam



On 25/03/2024 09:30, Simon Marlow wrote:
> On Fri, 22 Mar 2024 at 18:27, Simon Peyton Jones 
> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at 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 at maralorn.de
>     <mailto:malte.ott at 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
>         _______________________________________________

-- 
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