3 ms·

GHC language extensions are like C++ Technical Reports. They are a way to evolve the language without excessive red-tape on an opt-in basis, and periodically th

GHC language extensions are like C++ Technical Reports. They are a way to evolve the language without excessive red-tape on an opt-in basis, and periodically the ones that worked out make it into a new “standard”. It’s not really all the different from Python PEPs or Rust’s various proposals / nightly stuff. Just about every language has some form of this.

UncleMeat 4y ago
That's true. And when somebody says "oh you can just use GCC's special feature to make C++ tolerable" they rightly get pushback because only a portion of these features ever make it into a standard. This means that over time you end up with a codebase that is forever tied to these nonstandard features and might even end up being incompatible with major language changes. Or maybe the feature you adopted does get standardized but in a slightly different and incompatible way and now you've got a big problem on your hands. It is good for people to have ways of playing with a language so it evolves. It is (IMO) bad to suggest the adoption of these things as a means of making a language production-ready.
- benreesman 4y ago
  Just about every successful C/C++ project uses flags or intrinsics or whatever to some degree. It’s not unusual or particularly problematic. Linux famously uses a bunch of GCC stuff (though I gather that’s in decline) and non-standard defaults like ‘-fno-strict-aliasing’. And the extensions in the article are for the most part in the GHC2021 standard. So it’s more like, this is in C++20. Younger languages like Rust or Kotlin or something have less pressure for mechanisms like this because you have to get to a certain point in the language lifecycle before the tradeoff tilts from “let’s do a breaking change at a point release” to “let’s flag in the new behavior”, but if (as I expect) e.g. Rust lasts as long as C++ or Haskell, it will be be bedazzled with all kinds of flags and extensions and stuff too, how else do you grow a language for 40 years?
  - derefr 4y ago
    > how else do you grow a language for 40 years? You could introduce things in one version of the standard, and then remove them in the next release if people didn't like it, such that to get the feature you have to specifically use --std=2022a, no earlier, no later; and if you want your project to track the evolution of the language rather than getting stuck on a particular version, you'd have to rip use of such features back out. You could sort of think of it as if you had a dependencies lockfile which includes a version-constraint on the major version of the compiler; where every time there's a change in what code is accepted, that major version of the compiler goes up. Any change other than changing what code is accepted as valid goes into the lower semver fields; and gets replicated across all major versions of the compiler, where relevant. (Except that you don't have to do this by actually maintaining separate major-version branches of the compiler for every standards release; you can do it the way we currently do feature flags, only the only flag you get is which standard-version your project is written for.) I don't think I've ever seen anyone actually do this for a language/compiler; but it's a common approach used for protocol and API-client libraries, and seems to work well there.
  - pie_flavor 4y ago
    What's insufficient about the way Rust's already growing?
- hither_shores 4y ago
  > Or maybe the feature you adopted does get standardized but in a slightly different and incompatible way and now you've got a big problem on your hands. Haskell is de facto a single-implementation language: an extension is not going to be made incompatible with some future Haskell standard without having been long since deprecated in GHC.

UncleMeat 4y ago

That's true. And when somebody says "oh you can just use GCC's special feature to make C++ tolerable" they rightly get pushback because only a portion of these features ever make it into a standard. This means that over time you end up with a codebase that is forever tied to these nonstandard features and might even end up being incompatible with major language changes. Or maybe the feature you adopted does get standardized but in a slightly different and incompatible way and now you've got a big problem on your hands. It is good for people to have ways of playing with a language so it evolves. It is (IMO) bad to suggest the adoption of these things as a means of making a language production-ready.

benreesman 4y ago
Just about every successful C/C++ project uses flags or intrinsics or whatever to some degree. It’s not unusual or particularly problematic. Linux famously uses a bunch of GCC stuff (though I gather that’s in decline) and non-standard defaults like ‘-fno-strict-aliasing’. And the extensions in the article are for the most part in the GHC2021 standard. So it’s more like, this is in C++20. Younger languages like Rust or Kotlin or something have less pressure for mechanisms like this because you have to get to a certain point in the language lifecycle before the tradeoff tilts from “let’s do a breaking change at a point release” to “let’s flag in the new behavior”, but if (as I expect) e.g. Rust lasts as long as C++ or Haskell, it will be be bedazzled with all kinds of flags and extensions and stuff too, how else do you grow a language for 40 years?
- derefr 4y ago
  > how else do you grow a language for 40 years? You could introduce things in one version of the standard, and then remove them in the next release if people didn't like it, such that to get the feature you have to specifically use --std=2022a, no earlier, no later; and if you want your project to track the evolution of the language rather than getting stuck on a particular version, you'd have to rip use of such features back out. You could sort of think of it as if you had a dependencies lockfile which includes a version-constraint on the major version of the compiler; where every time there's a change in what code is accepted, that major version of the compiler goes up. Any change other than changing what code is accepted as valid goes into the lower semver fields; and gets replicated across all major versions of the compiler, where relevant. (Except that you don't have to do this by actually maintaining separate major-version branches of the compiler for every standards release; you can do it the way we currently do feature flags, only the only flag you get is which standard-version your project is written for.) I don't think I've ever seen anyone actually do this for a language/compiler; but it's a common approach used for protocol and API-client libraries, and seems to work well there.
- pie_flavor 4y ago
  What's insufficient about the way Rust's already growing?
hither_shores 4y ago
> Or maybe the feature you adopted does get standardized but in a slightly different and incompatible way and now you've got a big problem on your hands. Haskell is de facto a single-implementation language: an extension is not going to be made incompatible with some future Haskell standard without having been long since deprecated in GHC.