Funny enough, even your basic Hindley-Milner style type inference has exponential runtime in the worst case, even if you don't add any bells nor whistles.

In practice, people don't tend to write code that triggers that worst-case.

I like that you can mix and match GHC extensions even in the same project. So one library (or even just one module) might use some crazy and messy extensions, but you can still use it from vanilla Haskell.

http://dev.stephendiehl.com/hask/#language-extensions has a list of extensions and some judgement on them.

There are a few that are really neat, but don't really cause any mess:

For example, I really like TupleSections. They are not strictly necessary for anything, they are purely cosmetic / syntactic sugar. But they also don't cause any mess. https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/tupl...

Also: TypedHoles are really neat for developing, and will never show up in your final code. https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/type...

In contrast: GADTs are really important, but they get you pretty far away from Vanilla Haskell.

Yeah, I'm ok with that. I'm more after expressivity than safety or efficiency. Sometimes they're not separable, but confronted with the usual "we don't know how to efficiently compile that, so we won't allow you to express it", my response is always "the language is not the right level at which to choose such engineering tradeoffs - give me finer-grain control, and in program portions where it matters, I'll trade expressiveness for efficiency or safety... after maybe first trying caching and cloud parallelism and patience and external analysis and ... ".

Oops, I got carried away at the end there. Yes, maximally-restricted tolerable representation buys maximized compiler leverage. But might we more often metaprogram that out of diversely-performant maximal power, rather than bootstrapping it on performant but constraining circumscribed power?