Ich bin ein Anfänger mit Haskell und ich habe angefangen, Fehler ähnlich zu sehen:
%Vor% Ich arbeite innerhalb von ghci und mit ghc , aber nur aufgrund der Tatsache, dass es das erste war, das ich bei einer Suche gefunden habe.
Ich bin neugierig, ob dies die Art von Situation ist, die man vermeiden möchte, voranzukommen. 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
%Vor% Ich nehme an, dass sowohl a als auch b gleichzeitig aus der Liste lesen, was hier Probleme verursacht ...? 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 eine Eingabe.
[BEARBEITEN] Tut mir leid, wenn das nicht ganz klar war, aber meine Frage ist, ob die Einbeziehung von Glasgow (oder anderen) Erweiterungen als schlechte Praxis angesehen wird. Das obige Beispiel soll nur den Fehlertyp veranschaulichen, der diese Frage ausgelöst hat.
Geben Sie anstelle von alle GHC-Erweiterungen an, welche verwendet werden, indem Sie den Pragma-Mechanismus LANGUAGE verwenden:
Ich nehme an, dass sowohl
aals auchbliest von der Liste am gleiche Zeit verursacht hier Probleme ...? Damit, wenn die Glasgow-Erweiterungen die einzigen sind Mittel zur Unterstützung dieses Konstrukts ist es häufiger, um die Liste zu generieren ein anderer Weg oder einfach davon ausgehen, dass die Erweiterungen werden verfügbar sein?
Eine parallele Iteration über dieselbe Liste ist erlaubt. Das Problem ist, dass Parallelverständnisse im Haskell 98-Standard nicht definiert sind. Sie können einfach mit zip simuliert werden:
Erweiterungen selbst sind nicht schlecht - ein Großteil der Standardbibliothek verwendet Erweiterungen der einen oder anderen Art. Viele werden in Haskell , der nächsten Iteration des Haskell-Standards, berücksichtigt. 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 wirklich wissen, was Sie tun.
Jede Erweiterung, die in der HaskellExtensions-Wiki-Seite mit Unterstützung von zwei oder mehr Compilern aufgeführt ist, ist wahrscheinlich sicher zu bedienen.
GHC ist definitiv allgegenwärtig - ich denke, es ist der am häufigsten verwendete Haskell-Compiler, also wird es wahrscheinlich nicht zu viele Probleme 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 zum Beispiel auch ziemlich üblich.
Die Verwendung 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 daher an die Liste halten, die in Haskell Prime enthalten ist.
Ich würde vorschlagen, ein " , " anstelle von " | " 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 verlangen vom Leser eine Vertrautheit mit einer neuen Syntax und einem Verständnis dessen, was diese Syntax bedeutet. Beispiele hierfür 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 verwenden, wie John Millikin vorgeschlagen hat, oder den Code als unbekannten Vorschlag umgestalten.
+1 dons 'Vorschlag zur Verwendung der geplanten in Haskell Prime .
Haskell 2010 wird Ende 2009 veröffentlicht. Die Änderungen werden am 3. September 2009 auf dem Haskell Symposium bekannt gegeben.
Tags und Links haskell coding-style