2012-01-19 9 views
11

Mam projekt Haskell, który regularnie używa wielu funkcji językowych i chcę, aby blok rozszerzenia języka dla każdego pliku źródłowego był taki sam. Oto lista,haskell - jakikolwiek sposób na zrolowanie swojej własnej grupy pragmatów językowych?

{-# 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 #-} 

Może dla niektórych to jest złą praktyką, ale uważam rozszerzenia językowe być częścią „Haskell +”, które zwykle napisać kod. I chcę to być te same moduły szerokości. Na przykład kod NoImplicitPrelude zmienia się dramatycznie i chcę, aby był jednolity dla wszystkich modułów.

Pytanie: Jak mogę to osiągnąć, bez wklejenia bloku językowego do każdego pliku? To denerwuje, jak często uczę się nowej funkcji językowej, dodam ją do modułu A, następnie zacznę pracować nad modułem B i zdaję sobie sprawę, że muszę skopiować blok językowy z modułu A.

Po prostu FYI CPP pragma z #include ma nie załatwić sprawę! Z góry dziękuję.

+0

wstępną vious powiązane pytanie tutaj: http://stackoverflow.com/questions/6005382/haskell-ways-to-have-a-clean-import-block-re-exporting-modules-multiple-im – gatoatigrado

+2

Zdecydowanie sugerowałbym nie włączanie ' OverlappingInstances' na liście domyślnych rozszerzeń. – ehird

+0

@ehird, dobry punkt; jest używany okazjonalnie. – gatoatigrado

Odpowiedz

14

Zastosowanie Cabal jako system kompilacji i listy rozszerzeń języka chcesz w zakresie sekcji pliku project.cabalLibrary lub ExecutableExtensions. Następnie usuń blok LANGUAGE ze swoich plików źródłowych Haskell.

Zobacz Cabal User Guide, w tym akapit trzeci wstępu.


Ghci to miejsce, w którym wszystko spada. Mówi się o dodaniu polecenia cabal ghci, ale w międzyczasie jest trochę nieprzyjemnie.

Jeśli twój projekt jest biblioteką, możesz uruchomić ghci -package-conf dist/package.conf.inplace.

Jeśli chcesz załadować naświetlone modułów ghci, chciałbym zdefiniować flagę „trybie rozwoju” w swojej project.cabal:

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

... warunkowo wystawiać dodatkowe moduły w trybie rozwój:

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 

... i wyraźnie włączyć tryb rozwoju po uruchomieniu cabal configure:

$ cabal configure -f development 
+0

Wygląda dobrze. Tylko jedno pytanie: jak korzystać z ghci? (najlepiej na każdym module w projekcie - nie chcę edytować pliku cabal za każdym razem) – gatoatigrado

+1

Zobacz moją edycję. Czy poprawnie zrozumiałem, że nie chcesz edytować pliku cabal za każdym razem? – dave4420

+0

Przepraszamy za bycie niejasnym. Zmiany są zdecydowanie przydatne, ale nie sądzę, że tego szukam. Załóżmy, że pracuję nad modułem 'A'. Wtedy bez cabala mogę wpisać 'ghci A', a spróbuję załadować. Mogę przeładować z ': r', aż zadziała, a następnie przystąpić do pracy nad modułem' B', wpisując ': l B' (lub wychodząc i uruchamiając' ghci B'). – gatoatigrado

Powiązane problemy