2015-04-18 10 views
6

mi ritrovo con questo tipo di pragma molto nei miei progetti cabala per forzare GHC di costruire con opzioni specifiche:Haskell pragma: OPTIONS_GHC vs LINGUA

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

Ma quando vedo altre persone che utilizzano estensioni, hanno sempre dichiararlo in questo modo:

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

Tuttavia, quando ho caricare i file in GHCi che utilizzano il secondo metodo, GHC si lamenta sempre che sto usando un unrecognised pragma e prontamente fallisce.

Perché GHC non accetta il pragma LANGUAGE e quale delle due è una procedura migliore?


Nota: la mia versione GHC è up-to-date: 7.8.3, ma era 7.6 * quando questo si è verificato..

+0

Quale versione di GHC? Forse ne hai uno molto vecchio? Inoltre, fai attenzione all'usare un # # come il primo carattere di una riga quando CPP è abilitato (in questi casi, aggiungi uno spazio prima). – chi

+0

Scatto lungo, ma quale versione di GHC stai eseguendo? (Esegui 'ghc --version' nella tua shell per scoprirlo.) –

+0

Curioso. Puoi mostrare un intero file che dà questo errore? –

risposta

12

Utilizzare il pragma LANGUAGE è più bello. Invece di fornire un elenco di opzioni arbitrarie, è specifico solo per le estensioni della lingua. È inoltre progettato per essere portabile tra le implementazioni, come indicato nei documenti GHC; LANGUAGE

... consente di abilitare le estensioni della lingua in modo portatile. È intenzione che tutti i compilatori Haskell supportino il pragma LANGUAGE con la stessa sintassi, sebbene non tutte le estensioni siano supportate da tutti i compilatori, ovviamente. Si consiglia di utilizzare il prefisso LANGUAGE anziché OPTIONS_GHC, se possibile. [Il corsivo è mio]

Questa stessa lingua si presenta nella documentazione tutta la strada da GHC 6.6 (§7.10.4), quando LANGUAGE è stato introdotto, attraverso GHC 7.10.1 (§7.22.1), la release corrente (al momento della scrittura).

Un terzo modo per specificare le estensioni della lingua è quello di dichiararle nel file cabal.

Trovo anche che è comune l'uso di LANGUAGE pragma per dichiarare le estensioni utilizzate per un singolo file, ma utilizzando OPTIONS_GHC (a livello di singolo file) di solito è usato come una soluzione (ad esempio per disabilitare alcune avvertenze). Le persone preferiscono dichiarare le opzioni GHC a livello di progetto (con la cabala) non su singoli file, mentre per qualche motivo le estensioni della lingua vengono spesso utilizzate per file.

qui ci sono poche congetture selvagge perché il pragma LANGUAGE potrebbe non essere riconosciuti:

  • si dispone di una antica versione GHC (< 6,6)
  • non si dichiara come un file di intestazione pragma. Un pragma di intestazione file deve precedere la parola chiave module nel file. In altre parole, dovrebbe essere nella parte superiore del file (anche se potrebbe essere preceduto da altre direttive di intestazione del file)
+0

Se qualcuno ha più dubbi sul perché il pragma potrebbe non essere riconosciuto, aggiungili alla lista (per le generazioni future) – zudov

+6

Il motivo per cui le estensioni "LANGUAGE' sono per-file è assicurarsi che chiunque legga il file sappia quali estensioni ci sono giocare. È molto utile sapere se 'GeneralizedNewtypeDeriving',' OverlappingInstances', 'IncoherentInstances',' MonoLocalBinds', 'ScopedTypeVariables',' DataKinds' e/o 'PolyKinds' sono in gioco e questi (almeno) potrebbero non essere interamente ovvio dal resto della fonte. – dfeuer