[ghc-steering-committee] Fwd: GHC2023

[Joachim Breitner]

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 <arnaud.spiwack at tweag.io>:

> 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