"Extensions" has just turned out to be a sub-optimal moniker. They're not some third-party-compiler-plugins-to-be-installed-into-GHC, they're more like (rather involved) syntax sugars you can enable if needed. Each such "language feature" amounts to a tiny sub-compiler necessitating additional "core-to-core" and "core lint" (Core being the intermediate Typed Lambda Calculus representation all Haskell syntax sugars, built-in or "extension", compile down to) passes during compilation, which in GHC feels pretty sluggish to begin with.

So in pragmatic terms, enabling/disabling "extensions" lets you prevent some unnecessary processing loads during compilation.

Obviously one can do everything in "vanilla" (no-"extensions") Haskell just like one could express everything in raw Lambda Calculus. Syntax sugars as always allow for reducing patterns of verbosity --- those provided by "extensions" tend to be such patterns-of-verbosity that don't always occur in-all-projects-all-the-time, just in enough-projects-much-of-the-time.

Most of the aversion to them seems kneejerk "but my other language had another (or none at all) approach to this" --- never understood the strong opinions about GHC extensions. "Other-language" typically also delights in a culture of repetetively verbose syntax itself and no such APIs to hack new language constructs into the compiler in a plug-and-play manner (without forking).

And yes one can enable these via cabal file or GHC -X flags, but there's something to be said for per-module pragmas: they only activate where needed, and it aids the code reader as to what non-vanilla syntactic constructs are used in the-module-at-hand.

I'm aware that they're syntax sugar. I'm saying syntax sugar is bad. It's especially bad when there are dozens of mutually incompatible sugars. It's double especially bad when the base language is already one of the most complicated ones around.

> there are dozens of mutually incompatible sugars

If you think there are dozens then I challenge you to name a few ...

(I can't, off the top of my head, think of any but I don't deny there may be some.)

The base language is actually very small - you do need to know a lot on top to get anything done but arguably that's true with most languages.

There are very few mutually incompatible sugars.

> Hiding the ways in which your code isn't really Haskell (e.g. isn't going to be compatible with other random Haskell code) ...

Haskell code with any extensions enabled is pretty much always compatible with Haskell code with any other extensions enabled.

(I only said "pretty much" to hedge my bets. I literally can't think of any case where extensions could make your code incompatible with other code across a module boundary.)

Honestly this bugs me too. I don’t really see why the community doesn’t just decide the GHC really IS Haskell.

I’m aware there are other compilers but basically everyone uses GHC. So all these things that have to be turned on because they’re not “compatible“ with all the other compilers that no one else uses just add complexity for new users (and I suppose current users.)

GHC or not, you simple do not want all the extensions active all the time.

But are all those options compatible with each other?

Yes they are but they may not be compatible with all existing code as it is presently written. For example turning on OverloadedStrings can introduce type ambiguity in existing code where the type of a string literal cannot be deduced.

No, they are not, and some are useless

Edit: I guess not useless, but over time rendered as anti-features

Can you name some extensions that are not compatible with each other. I can't, off the top of my head, and I've been using Haskell for some years. (I don't deny there might be some, but I'm finding it hard to think of any.)

GeneralizedNewtypeDeriving and DeriveAnyClass (although this is fixed in 8.2)

yeah and we should also have decreted that IE6 was Internet in 2003 because that's what everyone was using too