Haskell: -fglasgow -exts sollte man Code vermeiden, der das erfordert?

Question

Ich bin ein Anfänger mit Haskell und ich habe begonnen, Fehler zu sehen ähnlich wie:

Illegal parallel list comprehension: use -fglasgow-exts 

Ich arbeite innerhalb von ghci und mit ghc aber nur aufgrund der Tatsache, dass es das erste war, das ich auf einer Suche gefunden habe.

Ich bin neugierig, ob das die Art von Situation ist, die man vermeiden möchte, vorwärts zu kommen. Alle Suchanfragen, die ich gefunden habe, erwähnen, dass diese Erweiterungen die zugrundeliegenden Einrichtungen offen legen, die nützlich sein können (oder auch nicht).

Ein spezifisches Beispiel ist

fibs = 0 : 1 : [ a + b | a <- fibs | b <- tail fibs ] 

Ich nehme an, dass sowohl a als auch b aus der Liste zur gleichen Zeit lesen, verursacht hier Probleme ...? Also, wenn die Glasgow-Erweiterungen das einzige Mittel sind, um dieses Konstrukt zu unterstützen, ist es üblicher, die Liste auf eine andere Weise zu erstellen oder einfach nur anzunehmen, dass die Erweiterungen verfügbar sein werden?

Vielen Dank im Voraus für jede Eingabe.

[EDIT] Es tut mir leid, wenn das nicht ganz klar war, aber meine Frage ist, ob die Einbeziehung von Glasgow (oder anderen) Erweiterungen als schlechte Übung angesehen wird. Das obige Beispiel soll nur den Fehlertyp veranschaulichen, der diese Frage ausgelöst hat.

Answer 1

Statt alle GHC Erweiterungen der Anforderung an, welche diejenigen verwendet werden, mit dem LANGUAGE Pragma-Mechanismus:

{-# LANGUAGE ParallelListComp #-} 
xy = [ x+y | x <- [1, 2, 3, 4] | y <- [5, 6, 7, 8] ] 

Ich gehe davon aus, dass beide a und b werden aus der Liste bei der Lektüre gleiche Zeit verursacht hier Probleme ...? Also, wenn die glasgow Erweiterungen die einzigen sind, bedeutet dieses Konstrukt zu unterstützen, ist es häufiger die Liste eine andere Art und Weise zu erzeugen, oder einfach mal davon aus, dass die Erweiterungen zur Verfügung stehen werden?

Parallele Iteration über die gleiche Liste ist zulässig. Das Problem ist, dass Parallelverständnisse im Haskell 98-Standard nicht definiert sind. Sie lassen sich leicht simuliert werden zip:

xy = [x+y | (x,y) <- zip [1, 2, 3, 4] [5, 6, 7, 8]] 

Extensions sich nicht schlecht sind - ein großer Teil der Standardbibliothek verwendet Erweiterungen, von einen oder anderen Art. Viele werden für die Aufnahme in Haskell', die nächste Iteration des Haskell-Standards, in Betracht gezogen.Einige Erweiterungen, z. B. GADTs, werden häufig in benutzerdefinierten Bibliotheken verwendet. Andere, wie Vorlagen oder inkohärente Instanzen, sind wahrscheinlich keine gute Idee, es sei denn, Sie wissen, was Sie tun, wirklich.

Jede Erweiterung, die in der HaskellExtensions wiki page mit Unterstützung von zwei oder mehr Compilern aufgeführt ist, ist wahrscheinlich sicher zu verwenden.

Answer 2

GHC ist definitiv allgegenwärtig - ich denke, es ist der am häufigsten verwendete Haskell-Compiler, also wird es wahrscheinlich nicht zu viel Mühe verursachen. Sie sollten jedoch immer versuchen, standardkonformen Code zu schreiben - vielleicht nicht für persönliche Projekte, aber für OSS oder Arbeit, definitiv.

Alles kann passieren, oder? Das kann eine plötzliche Änderung des Compilers auf halbem Weg durch Ihr Projekt sein.

Mit OSS verwenden verschiedene Leute verschiedene Compiler - HUGS ist auch zum Beispiel ziemlich üblich.

Answer 3

Was Sie wollen, ist:

fibs = 0 : 1 : zipWith (+) fibs (tail fibs) 

Dies liegt daran, Listenkomprehensionen wirklich nicht mit selbstbezogenen Listen arbeiten. Auch wenn GHC beliebter ist, erzeugt HUGS allgemein klarere Fehlermeldungen.

Answer 4

Verwenden von Erweiterungen ist in Ordnung. Markieren Sie sie speziell mit -XFoo oder LANGUAGE FOO. Welche Erweiterungen Sie verwenden möchten, liegt ganz bei Ihnen. Sie sollten sich an die Liste halten, die in Haskell Prime enthalten ist.

Answer 5

Ich würde vorschlagen, eine "," anstelle der "|" zu verwenden, aber dann habe ich gelernt, dass dies etwas anderes tut, als ich erwartet habe.

Daher sollten Sie neben der Portabilität auch die Lesbarkeit in Betracht ziehen. Die Verwendung von ungewöhnlichen Erweiterungen kann Ihren Code schwerer lesbar machen (für Personen, die mit den Erweiterungen nicht vertraut sind).

Einige Erweiterungen haben keine negativen Auswirkungen auf die Lesbarkeit (der resultierende Code ist offensichtlich), wie MultiParamTypeClasses, FlexibleContexts, FlexibleInstances.

Andere erfordern vom Leser eine Vertrautheit mit einer neuen Syntax und ein Verständnis dessen, was diese Syntax bedeutet. Beispiele für diese wären ParallelListComp, TypeFamilies, FunctionalDependencies. In diesem Fall würde ich empfehlen, diese Erweiterungen zu vermeiden, es sei denn, sie bringen einen Vorteil. In diesem Fall können Sie einfach zip wie von John Millikin vorgeschlagen verwenden oder den Code als unbekannt vorschlagen.

+1 Vorschlag für die Verwendung der geplanten in Haskell Prime aufgenommen werden.

Haskell 2010 soll Ende 2009 Der Satz von Änderungen freigegeben wird eingebaut werden am Haskell Symposium, 3. September 2009.