Which Haskell (GHC) extensions should users use/avoid? [closed]

Question

I have had the experience a few times now of having GHC tell me to use an extension, only to discover that when in using that extension I have made code far more complex when a simple refactor would have allowed me to stick with Haskell 98 (now 2010) and have a more straightforward solution.

On the other hand, there are also times when GADT's or Rank2Types (rarely RankNTypes) make for much less work and much cleaner code.

Which extensions tend generally to obscure the possibility of a better design, and which generally improve it? If there are some that do both, what should a user look for (be sure it true or not true of the solution they are intending) before deciding to use that extension?

(See also Should I use GHC Haskell extensions or not?)

Dozen

This question is similar: #10831257 – Duodecillion

Similar, but different. While that question is about the "safety" of extensions, John's issue is about the gains in designing code with and without extensions. – Pyrrolidine

This is a really tough one: some extensions are very general, and make new kinds of programming possible, some are highly targetted, aimed at solving a particular, impossible task. – Urceolate

Don Stewart: Yes, I agree. In retrospect, I wish I had focused the question and those extensions that effect the Type Checker. Thank you for your answer, none the less. – Dozen

Stephen Diehl made a list of extensions, saying if they are benign or not: dev.stephendiehl.com/hask/#language-extensions – Filing

Answer 1

An ad hoc list of morally "good" extensions, and morally "bad" ones - this is an aesthetic judgement!

The Good

• GADTs
• Parallel list comprehensions
• Pattern guards
• Monad comprehensions
• Tuple sections
• Record wild cards
• Empty data decls
• Existential types
• Generalized new type deriving
• MPTCs + FDs
• Type families
• Explicit quantification
• Higher rank polymorphism
• Lexically scoped tyvars
• Bang Patterns

The Bad

• SQL comprehensions
• Implicit parameters

The Ugly (but necessary)

• Template Haskell
• Unboxed types and tuples
• Undecidable, overlapping and incoherent instances -- usually means you have a misdesign.

Not sure

• Arrow notation
• View patterns

Urceolate

I don't totally agree about undecidable instances. The totality checker is very conservative and many reasonable instance declarations are disallowed. – Amagasaki

Yeah, that's a toss up. I think beginners turn it on too readily, when they should be redesigning, however, it does make certain impossible programs possible. – Urceolate

SQL comprehensions is bad and IncoherentInstances is not? – Teresetereshkova

added incoherence to the ugly-but-necessary section. haskell.org/ghc/docs/6.6/html/users_guide/type-extensions.html – Urceolate

In question earlier, generalized new type deriving became unsafe: https://mcmap.net/q/112037/-is-there-a-list-of-ghc-extensions-that-are-considered-39-safe-39/211885. The reason is some one can access data constructors, right? Can you show how is it done and what that mean, since you said it is good extension. – Clipclop

This isn't limited to generalized newtype deriving - Template Haskell can also access/use unexported constructors to break invariants other modules might have otherwise enforced. It seems to be to be too ignored - I've wanted this behavior guarded by a new LANGUAGE extension for a little while now. – Semitone

I generally consider ViewPatterns to be syntactic sugar more than anything else. – Torrez

@SamTobin-Hochstadt - loss of easy reasoning about code, amongst other things, #10857530 – Urceolate

@DonStewart, I would say that that "a domain-specific language is the ultimate abstraction" (Paul Hudak), and that metaprogramming is a vital tool for "easy reasoning about code". – Atreus

DSLs are great. And there are lots of good DSLs in Haskell that don't use meta-programming (none of Hudak's DSLs use TH...). I simply don't agree that meta-programming is vital for making code easier to reason about, as the semantics of staged computation is significantly more complicated than non-staged computations. – Urceolate

@DonStewart, that line of reasoning proves waaaay too much. It's obviously easier to reason about Haskell than about assembly, despite the fact that when you use GHC, you're using both. Compilers are just big metaprograms. – Atreus

@SamTobin-Hochstadt the takeaway message I got from asking the "What's so bad about Template Haskell?" question is not that metaprogramming is ugly, but that Template Haskell basically does not do a good enough job of implementing safe metaprogramming. I agree that careful use of metaprogramming can be a huge boon to reasoning about a program, since it allows you to step beyond the limitations of the original language, and enables forms of expression that are nearer to the "language" of the problem domain. – Tenuto

See also Taha on the difficulties of staged computation (e.g. TH), nii.ac.jp/shonan/seminar019/files/2012/05/… – Urceolate

What do these extensions do? – Waltman

What about MonadFailDesugaring? I would say it makes all programs safer. – Filing