[ghc-steering-committee] Fwd: GHC2023

[Arnaud Spiwack]

To chime in with data from other communities, in Rust there is a
concept of Edition [1]. They are, likewise, labelled by years.

In your project file (Cargo.toml), you write something like `edition = '2021'`.

This fixes a set of features. It is sold and perceived as a backward
compatibility mechanism. If I set my edition, later Rust compilers
will not break my code. If I want to benefit from new features which
are backward incompatible, I will need to change the edition, and risk
breakage then.

There appears to be a new edition in Rust every 3 years. Which seems
like a reasonable pace to me.


[1]: https://doc.rust-lang.org/edition-guide/index.html


On Tue, 8 Nov 2022 at 12:48, Joachim Breitner <mail at joachim-breitner.de> wrote:
>
> Hi Tom,
>
> thanks for your input! If I may (inadequadly) summarize what I read is
> that we should take into account stability and not just technical
> stability (your code doesn’t have to change as you upgrade your code),
> but also _perceived_ stability (there is GHC2021 and GH2023 and that’s
> confused).
>
> I agree that this is imporant, and worth thinking more about.
>
> In particular: How do other languages treat this? In one of my
> newsfeeds I recently read
>
> > Version 1.65.0 of the Rust language has been released. Improvements
> > include generic associated types, a new let...else statement, and
> > the ability to break from labeled blocks
>
> and also
>
> > Version 3.10.0 of the Python language has been released. There are a
> > lot of significant changes in this release, including the much-
> > discussed structural pattern-matching feature.
>
> so these (popular, non-scary) languages certainly don’t freeze their
> language, and do extend the language repeatedly. Why are they not
> preceived as unstable as Haskell is?
>
> (Here I am really talking about _perceived_ instability, not real
> instability in the sense of _breaking_ changes – the above extensions
> are AFAIK not breaking, and many of our Haskell extensions are not
> breaking.)
>
> It is because we have the concept of a language extension in the first
> place! And, on top of that, now the concept of the current version of
> GHC Haskell. If we didn’t have that in the first place, and no Haskell
> standard, it’d just be the case that GHC-9.2 happens to be the first
> version where you can, say, derive Functor, and that’s it.
>
> My idea of GHC20xx is that it brings us closer to the Rust or Python
> model: Unless you tell GHC you want something else, you get the latest
> stable (in the sense of proven, not in the sense of unchanging) set of
> language features.
>
> And if you want something else (e.g. opt-out of new extensions, or try
> out experimental ones), you have to explicitly ask for it (e.g. pin the
> language version with -XGHC2021, or enable -XFancyTypes). A bit like
> using Rust nightly, just less hassle…
>
> So if you don’t actively do something, you get the same experience as
> in rust or python … and at this point I wonder why this experience is
> perceived as different as in these languages?
>
> (Again, I am focusing here on non-breaking, additive extensions. How to
> handle breaking changes is yet another discussion, of course, and one
> where peeking at Python or Rust is not always showing us the best way
> to do it.)
>
> Cheers,
> Joachim
>
>
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee