Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Haskell pragmas: OPTIONS_GHC vs LANGUAGE

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.

like image 792
AJF Avatar asked Apr 18 '15 17:04

AJF


1 Answers

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)
like image 161
zudov Avatar answered Oct 01 '22 01:10

zudov