2012-01-19 12 views
11

Ho un progetto Haskell che usa regolarmente molte funzionalità linguistiche e voglio che il blocco di estensione della lingua per ogni file sorgente sia lo stesso. Ecco un elenco,haskell - un modo per lanciare il tuo gruppo di pragmi LANGUAGE?

{-# LANGUAGE Arrows, 
      BangPatterns, 
      DefaultSignatures, 
      DeriveDataTypeable, 
      DeriveFunctor, 
      EmptyDataDecls, 
      FlexibleContexts, 
      FlexibleInstances, 
      FunctionalDependencies, 
      GADTs, 
      GeneralizedNewtypeDeriving, 
      MultiParamTypeClasses, 
      NamedFieldPuns, 
      NoImplicitPrelude, 
      NoMonomorphismRestriction, 
      OverlappingInstances, 
      RankNTypes, 
      RebindableSyntax, 
      ScopedTypeVariables, 
      StandaloneDeriving, 
      TemplateHaskell, 
      TypeFamilies, 
      TypeOperators, 
      TypeSynonymInstances, 
      UndecidableInstances, 
      ViewPatterns #-} 

Forse per alcuni è cattiva pratica, ma ritengo estensioni del linguaggio di far parte del "Haskell +" che io di solito scrivere il codice. E, voglio che per essere gli stessi moduli in tutto. Ad esempio, lo NoImplicitPrelude cambia radicalmente la lingua e lo voglio uniforme per tutti i moduli.

Domanda: Come posso ottenere ciò senza incollare il blocco lingua in ogni file? Diventa fastidioso come spesso imparo una nuova lingua, aggiungila al modulo A, quindi inizi a lavorare sul modulo B e mi rendo conto che devo andare a copiare il blocco della lingua dal modulo A.

Cordiali saluti il ​​pragma CPP con un #include fa non fare il trucco! Grazie in anticipo.

+0

pre viziosa domanda correlata qui: http://stackoverflow.com/questions/6005382/haskell-ways-to-have-a-clean-import-block-re-exporting-modules-multiple-im – gatoatigrado

+2

Vorrei fortemente suggerire di non includere ' OverlappingInstances' nell'elenco delle estensioni predefinite. – ehird

+0

@ehird, buon punto; è usato occasionalmente però. – gatoatigrado

risposta

14

Uso cabala come sistema di compilazione, ed elencare le estensioni del linguaggio che si desidera nel campo Extensions della sezione Library o Executable del file project.cabal. Quindi rimuovere il blocco LANGUAGE dai file di origine Haskell.

Vedere Cabal User Guide, incluso il terzo paragrafo dell'introduzione.


Ghci è dove tutto cade. Si parla di aggiungere un comando cabal ghci, ma nel frattempo è un po 'icky.

Se il progetto è una libreria, è possibile eseguire ghci -package-conf dist/package.conf.inplace.

Se si desidera caricare i moduli non ancora esposte in ghci, mi definisco una bandiera "modalità di sviluppo" nel tuo project.cabal:

Flag development 
    Description:   Development mode: expose all modules, enable warnings. 
    Default:    False 

... esporre condizionalmente moduli aggiuntivi in ​​modalità di sviluppo:

Library 
    Exposed-modules:  My.Module, My.Module.Extra 
    if flag(development) 
    Exposed-modules: My.Module.Hidden, My.Module.Secret 
    GHC-Options:  -Wall 
    -- plus your extensions, etc 

... e attivare in modo esplicito modalità di sviluppo quando si esegue cabal configure:

$ cabal configure -f development 
+0

Sembra buono. Solo una domanda: come posso usare ghci? (preferibilmente su qualsiasi modulo nel progetto - Non voglio modificare il file cabal ogni volta) – gatoatigrado

+1

Vedere la mia modifica. Ho capito correttamente il tuo punto di non voler modificare il file cabal ogni volta? – dave4420

+0

Mi dispiace per non essere chiaro. Le modifiche sono sicuramente utili, ma non penso a quello che sto cercando. Supponiamo che sto lavorando al modulo 'A'. Quindi, senza cabal, posso digitare 'ghci A', e tenterà di caricarlo. Posso ricaricare con ': r', fino a quando non funziona, e quindi procedere al lavoro sul modulo' B', digitando ': l B' (o uscendo ed eseguendo' ghci B'). – gatoatigrado