63

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

Improve this question
5
  • This question is similar: stackoverflow.com/questions/10830757/…
    – huon
    Commented Jun 1, 2012 at 6:04
  • 1
    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.
    Commented Jun 1, 2012 at 8:07
  • 1
    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
    Commented Jun 1, 2012 at 11:45
  • 1
    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
    Commented Jun 1, 2012 at 18:58
  • Stephen Diehl made a list of extensions, saying if they are benign or not: dev.stephendiehl.com/hask/#language-extensions
    – Janus Troelsen
    Commented May 15, 2016 at 16:54

1 Answer 1

Reset to default
56

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
Improve this answer
15
  • 20
    I don't totally agree about undecidable instances. The totality checker is very conservative and many reasonable instance declarations are disallowed.
    – augustss
    Commented Jun 1, 2012 at 12:54
  • 9
    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.
    – Don Stewart
    Commented Jun 1, 2012 at 12:55
  • 3
    SQL comprehensions is bad and IncoherentInstances is not?
    – is7s
    Commented Jun 1, 2012 at 14:15
  • 2
    @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".
    – Sam Tobin-Hochstadt
    Commented Jun 2, 2012 at 20:31
  • 5
    @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.
    – Dan Burton
    Commented Jun 3, 2012 at 0:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.