2010-10-22 10 views
7

Cabal daje mi mieszane wiadomości. Kiedy mówię:Czy DeriveFunctor jest dobrze rozpoznawanym rozszerzeniem? Cabal wydaje się zdezorientowany.

Extensions: DeriveFunctor 

Mówi:

Warning: Unknown extensions: DeriveFunctor 

Ale kiedy mówię:

GHC-Options: -XDeriveFunctor 

Mówi:

Warning: Instead of 'ghc-options: -XDeriveFunctor' use 'extensions: 
DeriveFunctor' 

Na razie jestem po prostu dzieje korzystać z pragma {-# LANGUAGE DeriveFunctor #-}.

$ cabal --version 
cabal-install version 0.8.2 
using version 1.8.0.6 of the Cabal library 
$ ghc --version 
The Glorious Glasgow Haskell Compilation System, version 6.12.3 
$ basename $(mdfind haskell-platform | grep .dmg) 
haskell-platform-2010.2.0.0.i386.dmg 
+0

Którą wersję platformy GHC lub Haskell używasz> –

+0

Dodano więcej informacji o wersji. –

+0

Nie wiem o tym szczególnym ostrzeżeniu, ale myślę, że dodanie do tego pragma LANGUAGE w pliku jest najlepszą opcją. –

Odpowiedz

4

Według Hackage documentation, od Cabal-1.8.0.6 DeriveFunctor nie jest rozpoznawany. Jest to stosunkowo nowy dodatek do GHC i nie wydaje się mieć szerokiego zastosowania, więc nie jestem zaskoczony, że zostałby przeoczony przez Cabala. To powinno być prawdopodobnie zgłoszone jako błąd (żądanie funkcji?) W stosunku do Cabala.

@Tom Lokhorst ma rację, że pragma LANGUAGE jest najlepszą opcją. Nie lubię używać pola rozszerzeń Cabal, ponieważ wtedy wszystkie rozszerzenia są aktywne dla wszystkich modułów, których często nie chcę.

+1

OK Zgłoszono: http://hackage.haskell.org/trac/hackage/ticket/751 –

+1

Dziękujemy za przesłanie zgłoszenia błędu; Dodałem łatkę. –

7

Możesz nadal używać extensions: DeriveFunctor w pliku .cabal. Tak, to nie jest rozszerzenie, które jest obecnie znane Cabal, ale nadal możesz z niego korzystać i dopóki kompilator je rozpozna, to zadziała. Rzeczywiście Cabal sprawdzi, czy kompilator rozpoznaje rozszerzenie, mimo że Cabal sama o tym nie wie.

Istnieje centralny rejestr rozszerzeń w module Language.Haskell.Extension. Celem tego rejestru jest to, aby różne kompilatory mogły uzgodnić te same nazwy podczas wdrażania tych samych rozszerzeń. W przeszłości mieliśmy przypadki, w których autorzy różnych kompilatorów przypadkowo nadawali różne nazwy tej samej koncepcji rozszerzenia. Nie wszystkie rozszerzenia muszą zostać zarejestrowane. Sensowne jest, aby nie rejestrować rozszerzeń, które są nadal wysoce eksperymentalne, na przykład rozszerzenia DPH "PArr" nadal nie są rejestrowane. Hackage wymaga, aby wszystkie załadowane pakiety używały tylko znanych zarejestrowanych rozszerzeń, co ma sens, ponieważ jeśli rozszerzenie jest wystarczająco przygotowane do użycia w rozproszonym pakiecie, można się zarejestrować.

W tym szczególnym przypadku twórcy GHC zapomnieli zarejestrować rozszerzenie.

Warto również zauważyć, że od wersji Cabal-1.10 pole extensions jest dzielone na dwie części: default-extensions i other-extensions. Odnosi się to do kwestii, którą John wskazuje w swojej odpowiedzi, że poprzednie zachowanie polega na tym, że wszystkie rozszerzenia są aktywne dla wszystkich modułów, co uznajemy za błąd. Pole other-extensions pozwala na umieszczenie rozszerzeń używanych w niektórych modułach (tj. Z pragma LANGUAGE). Cabal w końcu wymusi wymuszenie, że wszystkie są wymienione, tak jak wymaga to wszystkich zależności pakietów. Zależności językowe również są zależne.

Powiązane problemy