There are some extensions like UndecidableInstances or OverloadableSyntax which are great in specific files but which would be awful in the entire codebase.

As a Java programmer, I don’t have to have the equivalent of 75 LANGUAGE pragmas to be able to use the features in Java 8 instead of what Java 1.1 shipped with.

It’s nice there’s a way not to put them at the top of every single file but they still exist.

There must be some reasonable subset that basically everyone uses and should just be included in the language.

One of the declared goals during the initial design phase of the Haskell language was to "... be usable as a basis for further language research." From "A History of Haskell: Being Lazy with Class" available at https://www.microsoft.com/en-us/research/wp-content/uploads/.... Language pragmas feels like a nice tool to support this goal.

I think the equivalent is packages which provide annotations. There are plentiful of such packed providing variations of "notNull". It seems even worse than extensions, as they are third party.

> There must be some reasonable subset that basically everyone uses and should just be included in the language.

Well, there is. The problem is that the last reasonable subset is 7 years old, and Haskell is evolving quickly.

There's a new standard scheduled to 2020.

There used to be -fglasgow-exts, but they removed that. I honestly don't really see the big deal. It's like feature flags for C or C++ compilers

actually in java you can have compiler extensions aswell. they are just not included by default.

Getting everyone to come to a consensus on what should or shouldn't be included would be very difficult. Then there's also the issue of backwards compatibility. At the end of the day they're opt in so you can just simply not use them.

Optimizing individually for every individual has a tendency to de-optimize the community as a whole.

This is one of those things that seriously limits Haskell's growth. It's something for new users to bounce off of, and that contributes to Haskell's reputation as a write-only language.

Hiding the ways in which your code isn't really Haskell (e.g. isn't going to be compatible with other random Haskell code) doesn't strike me as a fix. Why are there so many extensions in the first place?

"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