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

Community
  • 1
  • 1
John F. Miller
  • 26,961
  • 10
  • 71
  • 121
  • This question is similar: http://stackoverflow.com/questions/10830757/is-there-a-list-of-ghc-extensions-that-are-considered-safe – huon Jun 01 '12 at 06: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. Jun 01 '12 at 08: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 Jun 01 '12 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 Jun 01 '12 at 18:58
  • Stephen Diehl made a list of extensions, saying if they are benign or not: http://dev.stephendiehl.com/hask/#language-extensions – Janus Troelsen May 15 '16 at 16:54

1 Answers1

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
Don Stewart
  • 137,316
  • 36
  • 365
  • 468
  • 20
    I don't totally agree about undecidable instances. The totality checker is very conservative and many reasonable instance declarations are disallowed. – augustss Jun 01 '12 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 Jun 01 '12 at 12:55
  • 3
    SQL comprehensions is bad and `IncoherentInstances` is not? – is7s Jun 01 '12 at 14:15
  • added incoherence to the ugly-but-necessary section. http://www.haskell.org/ghc/docs/6.6/html/users_guide/type-extensions.html – Don Stewart Jun 01 '12 at 15:59
  • 1
    In question earlier, generalized new type deriving became unsafe: http://stackoverflow.com/q/10830757/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. – demi Jun 01 '12 at 16:26
  • 1
    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. – Thomas M. DuBuisson Jun 01 '12 at 19:53
  • 1
    I generally consider `ViewPatterns` to be syntactic sugar more than anything else. – John L Jun 02 '12 at 08:14
  • 1
    @SamTobin-Hochstadt - loss of easy reasoning about code, amongst other things, http://stackoverflow.com/questions/10857030/whats-so-bad-about-template-haskell – Don Stewart Jun 02 '12 at 18:06
  • 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 Jun 02 '12 at 20:31
  • 2
    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. – Don Stewart Jun 02 '12 at 20:59
  • @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. – Sam Tobin-Hochstadt Jun 02 '12 at 22:17
  • 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 Jun 03 '12 at 00:43
  • 1
    See also Taha on the difficulties of staged computation (e.g. TH), http://www.nii.ac.jp/shonan/seminar019/files/2012/05/Staging-15-Years-Later.pdf – Don Stewart Jun 03 '12 at 14:54
  • What do these extensions do? – PyRulez Nov 29 '13 at 18:41
  • What about MonadFailDesugaring? I would say it makes all programs safer. – Janus Troelsen May 15 '16 at 16:50