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.
Using the
LANGUAGEpragma 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;LANGUAGEThis same language shows up in the docs all the way from GHC 6.6 (§7.10.4), when
LANGUAGEwas 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
LANGUAGEpragma to declare used extensions for a single file, but usingOPTIONS_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
LANGUAGEpragma might not be recognised:modulekeyword 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)