Haskell pragmas: OPTIONS_GHC vs LANGUAGE

Question

I find myself using this sort of pragma a lot in my cabal projects to force GHC to build with specific options:

{-# OPTIONS_GHC -XFlexibleInstances -XRankNTypes ... #-}

But when I see other people using extentions, they always declare it in this way:

{-# LANGUAGE FlexibleInstances, RankNTypes, ... #-}

However, when I load files in GHCi which use the latter method, GHC always complains that I'm using an unrecognised pragma and promptly fails.

Why does GHC not accept the LANGUAGE pragma, and which of the two is better practice?

---

Note: my GHC version is up-to-date: 7.8.3, but was 7.6.* when this occurred.

Conidiophore

Which GHC version? Maybe you have a very old one? Also beware of using a # as the very first character of a line when CPP is enabled (in such cases, add a space before that). – Maros

Long shot, but what version of GHC are you running? (Run ghc --version in your shell to find out.) – Silveira

Curious. Can you show an entire file that gives this error? – Pus

Make sure that this line is a very first line of a file – Illusage

LANGUAGE pragmas have worked since 6.8.1. I really think we need a whole file to see what's wrong. – Pus

Notice 7.8.3 is not "100% up-to-date". There's 7.8.4 and 7.10.1. Not that any of these versions has issues with LANGUAGE pragma - it sounds like you have a typo in the pragma or other issues. – Epigoni

@ØrjanJohansen I searched around my project directory, but I can't seem to find the file in which I first discovered the problem, but now that zudov mentions it, I think I may have declared it after the module name. – Conidiophore

@AJFarmar Hmm. That might not be it. If you put the pragma after module declaration there would be no error, but GHC would simply consider it as a comment (7.8.4). – Illusage

Answer 1

Using the LANGUAGE pragma is nicer. Instead of giving a list of arbitrary options it is specific only to language extensions. It's also designed to be portable between implementations, as mentioned in the GHC docs; LANGUAGE

…allows language extensions to be enabled in a portable way. It is the intention that all Haskell compilers support the LANGUAGE pragma with the same syntax, although not all extensions are supported by all compilers, of course. The LANGUAGE pragma should be used instead of OPTIONS_GHC, if possible. [Emphasis added]

This same language shows up in the docs all the way from GHC 6.6 (§7.10.4), when LANGUAGE was introduced, up through GHC 7.10.1 (§7.22.1), the current (at time of writing) release.

A third way of specifying language extensions would be to declare them in the cabal file.

I also find that it's common to use LANGUAGE pragma to declare used extensions for a single file, but using OPTIONS_GHC (on a level of single file) is usually used as a workaround (e.g. to disable some warnings). People prefer to declare GHC options project-wide (with cabal) not on individual files, whereas for some reason language extensions are often used on per-file basis.

Here are a few wild guesses why the LANGUAGE pragma might not be recognised:

• You have an ancient GHC version (< 6.6)
• You do not declare it as a file-header pragma. A file-header pragma must precede the module keyword in the file. In other words, it should be at the very top of the file (though it might be preceded by other file-header pragmas)

Illusage

If anyone have more guesses why the pragma might be not recognised, please add them to the list (for future generations) – Illusage

The reason LANGUAGE extensions are often per-file is to ensure that anyone reading the file knows what extensions are in play. It's very good to know whether GeneralizedNewtypeDeriving, OverlappingInstances, IncoherentInstances, MonoLocalBinds, ScopedTypeVariables, DataKinds, and/or PolyKinds are in play, and these (at least) may not be entirely obvious from the rest of the source. – Copyright