Gibt es einen Haskell -Compiler oder Präprozessor, der eine strenge Bewertung verwendet?

Question

Ich suche einen Haskell -Compiler, der standardmäßig eine strenge Bewertung anstelle einer faulen Bewertung verwendet. Ich würde nur OCAML verwenden, aber Haskells Syntax ist es so viel besser als OCAMLs (und Haskell ist rein und verfügt über coole Funktionen wie Typklassen).

Ich würde wirklich eher nicht ständig gesagt !s und $!s über mein Programm. Ein Compiler mit einem Schalter oder einem Präprozessor, der die strengen Annotationen einfügen, wäre wirklich schön. Es wäre auch hilfreich, wenn es eine Möglichkeit gäbe, an bestimmten Orten eine faule Bewertung zu verwenden, nur für den Fall, dass ich so etwas wie eine unendliche Liste möchte (ich werde es wahrscheinlich nie tun).

Bitte versuchen Sie nicht, mich davon zu überzeugen, dass die faule Bewertung besser ist, ich brauche die Leistung wirklich. IIRC, Simon Peyton Jones sagte sogar, dass die faule Bewertung nicht wirklich notwendig war, es war hauptsächlich, um sie daran zu hindern, die Sprache unrein zu machen.

Answer 1

Wenn Sie einen Haskell -Compiler haben, der eine strenge Bewertung verwendet, kompilieren Sie Haskell nicht. Faulheit Nicht-Strengheit ist Teil der Haskell-Spezifikation!

Es gibt jedoch Alternativen.

• DDC ist ein Versuch, eine explizit faule Variante von Haskell zu erstellen, die Dinge wie destruktives Update unterstützt und gleichzeitig den Rest von Haskells Güte beibehält. Es gibt ein Problem: Der Compiler ist derzeit nur im α-Stadium, obwohl er zumindest nutzbar zu sein scheint.

• Erstellen Sie einen Präprozessor, wie es andere getan haben.

• Lernen Sie, Haskell „den richtigen Weg“ zu verwenden. Wenn Sie Ihren Testfall auf etwas vereinfachen können, das öffentlich in der Lage ist, können Sie ihn auf dem veröffentlichen Haskell-Café-Mailingliste, wo Menschen mit solchen Fragen zu den Auswirkungen der Nichtstraktalität sehr hilfreich sind.

Answer 2

Ich würde wirklich lieber nicht ständig auf mein Programm und $!

Sie machen es falsch, wenn Sie so Haskell programmieren :) Sie müssen das einfach nicht tun. Verwenden Sie GHC, verwenden Sie -o2, verwenden Sie gegebenenfalls strenge Datentypen und verwenden Sie gegebenenfalls faule. Gehen Sie nicht davon aus, dass Faulheit ein Problem sein wird - es ist eine Lösung für viele Probleme.

Answer 3

In der Vergangenheit gab es zwei Versuche, Haskell strikt zu bewerten:

• Jan-Willem Maessens Eifrig Haskell
• Rob Ennals Doktorarbeit

Beide konzentrierten sich jedoch darauf, sich an Haskells nicht-strenge Semantik zu halten, aber eine meist strenge Bewertungsstrategie zu verwenden, anstatt die Semantik tatsächlich zu ändern, und weder wirklich das Licht des Tages sah.

EDIT: Martijns Vorschlag von strengen Plugin sieht für Ihre Zwecke ideal aus, da er tatsächlich das tut, was Sie wollen, und der Autor ist immer noch in der Haskell-Community aktiv, ich hatte es vergessen.

Answer 4

Siehe auch GHC-Strict-Plugin, ein Beispiel für GHC -Plugin -Framework, beschrieben in der Monad -Leser 12.

Answer 5

Ich fühle deinen Schmerz. Meine größte Pita in meiner täglichen Programmierung ist es mit diesen zu tun!@#$%^& (Space Leaks.

Wenn es jedoch hilft, lernen Sie mit der Zeit (auf die harte Tour) darüber, wie Sie damit umgehen können, und es wird besser. Aber ich warte immer noch darauf, dass Andy Gill mit seinem magischen Raum -Leck -Profiler herauskommt, um alle meine Probleme zu beheben. (Ich nehme mir beim letzten ICFP seinen Kommentar an, dass er diese coole Idee als Versprechen, sie umzusetzen, ausgedacht hatte.)

Ich werde nicht versuchen, Sie davon zu überzeugen, dass die faule Bewertung das Beste auf der Welt ist, aber es gibt bestimmte gute Punkte. Ich habe einige Stream-Processing-Programme, die Lazy List durch jede Vielfalt von Kombinatoren, die glücklich auf Gigabyte von Daten laufen, während nur 3,5 MB Speicher verwendet (von denen mehr als 2 MB GHC-Laufzeit ist). Und jemand schlauer als ich letztes Jahr auf mich hingewiesen habe, dass Sie als typischer Haskell -Programmierer wirklich überrascht wären, wie sehr Sie von der faulen Bewertung abhängen.

Aber was wir wirklich brauchen, ist ein wirklich gutes Buch zum Umgang mit fauler Bewertung in der realen Welt (das sich nicht so von der akademischen Welt unterscheidet, außer dass sie einfach kein Papier veröffentlicht haben, und wir bekommen Kunden nach uns nach uns kommen mit Messern), die die meisten Probleme in Bezug auf dies in Bezug auf dies bedecken und uns vor allem ein intuitives Gefühl dafür geben, was unserem Haufen explodieren und was nicht.

Ich glaube nicht, dass dies eine neue Sache ist; Ich bin sicher, dass auch andere Sprachen und Architekturen dies durchgemacht haben. Wie haben sich die ersten Programmierer, die sich mit Hardware -Stapeln und all dem befassen, schließlich mit Hardware -Stapeln umgehen? Nicht so gut, ich wette.

Answer 6

Ich denke, dass Jan-Willem Maessan's PH -Compiler ist/war streng. Der nächstgelegene am nächsten ist Robert Ennals spekulative Bewertungsgabel für GHC 5. Die Spec_eval -Gabel ist nicht streng, sondern optimistisch bewertet. Ich weiß nicht, ob eine davon immer noch aktuell/nutzbar/usw. ist.

Answer 7

Die Verwendung von NFDATA und RNF überall ist keine Lösung, da dies bedeutet, dass es wiederholt große Strukturen durchquert, die bereits bewertet wurden.

Das Einführungskapitel von Ben Lippmeiers Doktorarbeit (über DDC) handelt und es wird als Effekt angesehen, der vom Typ-and-Effect-System von DDC verfolgt und verwaltet wird.

Answer 8

Ich habe kürzlich einige Arbeiten in diesem Bereich gesehen:

https://ghc.haskell.org/trac/ghc/wiki/strictpragma

Hier können Sie in der GHC -Status -Update von SPJ hier ein bisschen darüber hören:

http://youtu.be/ex79k4lvjno?t=9M33S(Link beginnt am relevanten Stück um 9:33)

Answer 9

Ich suche einen Haskell -Compiler, der standardmäßig eine strenge Bewertung anstelle einer faulen Bewertung verwendet.

Ein solcher Compiler wäre kein Haskell -Compiler. Wenn du Ja wirklich Wenn Sie wollen, könnten Sie in Betracht ziehen, um sie zu setzen {-# LANGUAGE Strict #-} Pragmas in Ihren Dateien. Dies funktioniert mit GHC 8.0.2, 8.2.2 und 8.4.1, auch bekannt als die letzten drei Veröffentlichungen des Compilers.

Es wäre auch hilfreich, wenn es eine Möglichkeit gäbe, an bestimmten Stellen eine faule Bewertung zu verwenden, nur für den Fall, dass ich so etwas wie eine unendliche Liste möchte

Es gibt keine solche Methode. Verwenden Sie stattdessen GHC, wie es beabsichtigt war - als faule Sprache. Das Lernen, über Ihren Code, Ihr Profil und die korrekte Verwendung von Funktionsdatenstrukturen nachzudenken, ist weitaus nützlicher, als überall strenge Pragmas anwenden. GHC hat bereits einen Strengeanalysator.

(Ich werde es wahrscheinlich nie tun).

Genau das ist die Autoren von LLVM-HS Gedanke Wenn sie sich entschieden haben, einen strengen Zustandsmonaden zu verwenden, anstatt einen faulen. Stattdessen verursachte es einen unerwarteten Fehler auf der Straße. Faulheit und Rekursion gehen Hand in Hand.

Bitte versuchen Sie nicht, mich davon zu überzeugen, dass die faule Bewertung besser ist, ich brauche die Leistung wirklich.

Ich bin zweifelhaft. Dies ist tatsächlich das, was Sie wollen, wenn es nicht zuverlässig die Leistung des Haskell -Codes erhöht, während gleichzeitig vorhandenen Code gebrochen und vorhandene Ressourcen unbrauchbar werden. Wenn Sie auf diese Weise Programme schreiben möchten, verwenden Sie bitte einfach OCAML oder Scala und lassen Sie die Haskell -Community in Ruhe.

IIRC, Simon Peyton Jones sagte sogar, dass die faule Bewertung nicht wirklich notwendig war, es war hauptsächlich, um sie daran zu hindern, die Sprache unrein zu machen.

Das ist nicht wahr. Sie können mehr über die tatsächliche Geschichte von Haskell lesen hier

Answer 10

Es gibt auch seqaid, was in der Mitte des faulen Streifenspektrums abzielt.

SEQAID ist ein GHC-Plugin, das eine nicht-invasive automatische Instrumentierung von Haskell-Projekten für die dynamische Strenge (und Parallelität) Kontrolle bietet. Dies beinhaltet bald eine Optimierung für automatisierte Leerverletzungen mit minimaler Striktierung.

Answer 11

Sie haben sich eindeutig über den Wert der strengen Bewertung entschieden, aber ich denke, Sie fehlen den Sinn, Haskell zu verwenden. Die faule Bewertung von Haskell ermöglicht viel flexiblere Optimierungsstrategien, die vom Compiler/Dolmetscher angewendet werden können. Das Erzwingen Ihrer eigenen Strenge überschreibt den Optimierer. Am Ende wird die Verwendung einer übermäßigen strengen Bewertung niemals so effizient sein wie die automatisierte Optimierung. Versuchen Sie eine Faltungssumme über eine Folge von Zahlen in GHCI, mit und dann ohne faule Bewertung. Sie können den Unterschied ganz klar erkennen - in diesem Fall ist die faule Bewertung immer schneller.