Re: [ghc-steering-committee] Fwd: GHC2023

Thanks for that! Do I also have to bump the edition if I want to get my hands on new non-breaking features (e.g. new syntax that simply wasn't legal before)? 10.11.2022 10:19:06 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 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@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