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

64
votes

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?)

1
haskelllanguage-extension
This question is similar: stackoverflow.com/questions/10830757/… – huon
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. – Riccardo T.
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. – Don Stewart
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. – John F. Miller
Stephen Diehl made a list of extensions, saying if they are benign or not: dev.stephendiehl.com/hask/#language-extensions – Janus Troelsen

1 Answers

56
votes

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