Chapter 7. GHC Language Features

Table of Contents
7.1. Language options
7.2. Unboxed types and primitive operations
7.3. Type system extensions
7.4. Assertions
7.5. Pattern guards
7.6. Parallel List Comprehensions
7.7. Pragmas
7.8. Rewrite rules
7.9. Generic classes
7.10. Generalised derived instances for newtypes
7.11. Concurrent and Parallel Haskell
7.12. Haskell 98 vs. Glasgow Haskell: language non-compliance

As with all known Haskell systems, GHC implements some extensions to the language. To use them, you'll need to give a -fglasgow-exts option.

Virtually all of the Glasgow extensions serve to give you access to the underlying facilities with which we implement Haskell. Thus, you can get at the Raw Iron, if you are willing to write some non-standard code at a more primitive level. You need not be “stuck” on performance because of the implementation costs of Haskell's “high-level” features—you can always code “under” them. In an extreme case, you can write all your time-critical code in C, and then just glue it together with Haskell!

Before you get too carried away working at the lowest level (e.g., sloshing MutableByteArray#s around your program), you may wish to check if there are libraries that provide a “Haskellised veneer” over the features you want. See Haskell Libraries.

7.1. Language options

These flags control what variation of the language are permitted. Leaving out all of them gives you standard Haskell 98.

-fglasgow-exts:

This simultaneously enables all of the extensions to Haskell 98 described in Chapter 7, except where otherwise noted.

-fno-monomorphism-restriction:

Switch off the Haskell 98 monomorphism restriction. Independent of the -fglasgow-exts flag.

-fallow-overlapping-instances, -fallow-undecidable-instances, -fallow-incoherent-instances, -fcontext-stack

See Section 7.3.3.3. Only relevant if you also use -fglasgow-exts.

-finline-phase

See Section 7.8. Only relevant if you also use -fglasgow-exts.

-fgenerics

See Section 7.9. Independent of -fglasgow-exts.

-fno-implicit-prelude

GHC normally imports Prelude.hi files for you. If you'd rather it didn't, then give it a -fno-implicit-prelude option. The idea is that you can then import a Prelude of your own. (But don't call it Prelude; the Haskell module namespace is flat, and you must not conflict with any Prelude module.)

Even though you have not imported the Prelude, all the built-in syntax still refers to the built-in Haskell Prelude types and values, as specified by the Haskell Report. For example, the type [Int] still means Prelude.[] Int; tuples continue to refer to the standard Prelude tuples; the translation for list comprehensions continues to use Prelude.map etc.

With one group of exceptions! You may want to define your own numeric class hierarchy. It completely defeats that purpose if the literal "1" means "Prelude.fromInteger 1", which is what the Haskell Report specifies. So the -fno-implicit-prelude flag causes the following pieces of built-in syntax to refer to whatever is in scope, not the Prelude versions:

  • Integer and fractional literals mean "fromInteger 1" and "fromRational 3.2", not the Prelude-qualified versions; both in expressions and in patterns.

  • Negation (e.g. "- (f x)") means "negate (f x)" (not Prelude.negate).

  • In an n+k pattern, the standard Prelude Ord class is still used for comparison, but the necessary subtraction uses whatever "(-)" is in scope (not "Prelude.(-)").

Note: Negative literals, such as -3, are specified by (a careful reading of) the Haskell Report as meaning Prelude.negate (Prelude.fromInteger 3). However, GHC deviates from this slightly, and treats them as meaning fromInteger (-3). One particular effect of this slightly-non-standard reading is that there is no difficulty with the literal -2147483648 at type Int; it means fromInteger (-2147483648). The strict interpretation would be negate (fromInteger 2147483648), and the call to fromInteger would overflow (at type Int, remember).