Personal tools

Use of language extensions

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
(taken from a Haskell-Cafe mail)
 
(template haskell, links to language extensions)
 
(6 intermediate revisions by 3 users not shown)
Line 3: Line 3:
 
Every required language extension and every imported library which on its own depends on such an extension,
 
Every required language extension and every imported library which on its own depends on such an extension,
 
causes some of the following problems:
 
causes some of the following problems:
  +
* The use of a language extension might indicate a design flaw! Sometimes you write an incorrect program and the compiler suggests to use a language extension to resolve that. It is a quick fix to solve the problem by enabling the extension, but if you do not understand the implications, you run into problems later. See e.g. [[List instance]], [[Overlapping instance]].
 
* It limits the range of Haskell compilers you can use.
 
* It limits the range of Haskell compilers you can use.
 
* According to the availability of compilers on different platforms, it will also limit the range of machines it can be run on.
 
* According to the availability of compilers on different platforms, it will also limit the range of machines it can be run on.
 
* It complicates the installation, if a user has to install a particular compiler to use your library.
 
* It complicates the installation, if a user has to install a particular compiler to use your library.
 
* Many extensions are complicated enough to produce even more incomprehensible error messages, than errorneous Haskell 98 programs.
 
* Many extensions are complicated enough to produce even more incomprehensible error messages, than errorneous Haskell 98 programs.
  +
* Even with the same compiler, in a year or two your code might need fixing if the extension or implementation is sufficiently experimental (for example, the rules for what type-signatures GADTs require, has changed from GHC 6.4 to 6.6 to 6.8 to 6.10). People who depend on your library may be impatient to upgrade to the newest version of GHC.
   
 
We suggest the following hierarchy of complexity with respect to types:
 
We suggest the following hierarchy of complexity with respect to types:
Line 12: Line 14:
 
* H98 type classes
 
* H98 type classes
 
* Fancier instance heads (but still single-parameter, non-overlapping)
 
* Fancier instance heads (but still single-parameter, non-overlapping)
* Existential and local universal quantification
+
* [[Existential type|Existential]] and local universal quantification
* GADTs (I'm still uncertain about this judgement, but they seem to be less troublesome than...)
+
* [[GADT]]s (I'm still uncertain about this judgement, but they seem to be less troublesome than...)
* Multiparameter type classes
+
* Multiparameter type classes with [[functional dependencies]]
  +
* [[Multi-parameter type classes]] including [[undecidable instance]]s, [[overlapping instance]]s
  +
* [[Template Haskell]]
   
  +
We recommend to explicitly switch on language extensions that are needed using the LANGUAGE pragma
  +
instead of switching them on all at once using the <code>-fglasgow-exts</code> compiler flag.
   
See http://www.haskell.org/pipermail/haskell-cafe/2005-May/010085.html
+
== See also ==
  +
  +
* Initiating mail on Haskell Cafe: [http://www.haskell.org/pipermail/haskell-cafe/2005-May/010085.html When to use fancy types]
  +
* GHC ticket on [http://hackage.haskell.org/trac/ghc/ticket/3085 warn about language extensions that are not used]
  +
* Haskell Cafe on [http://www.haskell.org/pipermail/haskell-cafe/2009-April/059206.html List and description of language extensions]
   
 
[[Category:Style]]
 
[[Category:Style]]

Latest revision as of 10:05, 23 December 2010

Haskell compilers are full of experimental features. However, when it comes to designing libraries one should carefully think about which extensions to use and which not. Every required language extension and every imported library which on its own depends on such an extension, causes some of the following problems:

  • The use of a language extension might indicate a design flaw! Sometimes you write an incorrect program and the compiler suggests to use a language extension to resolve that. It is a quick fix to solve the problem by enabling the extension, but if you do not understand the implications, you run into problems later. See e.g. List instance, Overlapping instance.
  • It limits the range of Haskell compilers you can use.
  • According to the availability of compilers on different platforms, it will also limit the range of machines it can be run on.
  • It complicates the installation, if a user has to install a particular compiler to use your library.
  • Many extensions are complicated enough to produce even more incomprehensible error messages, than errorneous Haskell 98 programs.
  • Even with the same compiler, in a year or two your code might need fixing if the extension or implementation is sufficiently experimental (for example, the rules for what type-signatures GADTs require, has changed from GHC 6.4 to 6.6 to 6.8 to 6.10). People who depend on your library may be impatient to upgrade to the newest version of GHC.

We suggest the following hierarchy of complexity with respect to types:

We recommend to explicitly switch on language extensions that are needed using the LANGUAGE pragma instead of switching them on all at once using the -fglasgow-exts compiler flag.

[edit] See also