[ghc-steering-committee] Fwd: GHC2023

[Joachim Breitner]

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/