In der Programmiersprache-Theorie, der faulen Einschätzung oder dem Anruf durch das Bedürfnis ist eine Einschätzungsstrategie, die die Einschätzung eines Ausdrucks verzögert, bis der Wert davon wirklich (nichtstrenge Einschätzung) erforderlich ist, und der auch wiederholte Einschätzungen (das Teilen) vermeidet. Das Teilen kann die Laufzeit von bestimmten Funktionen durch einen Exponentialfaktor über andere nichtstrenge Einschätzungsstrategien wie Anruf namentlich reduzieren.

Die Vorteile der faulen Einschätzung schließen ein:

• Leistung nimmt wegen des Vermeidens unnötiger Berechnungen und Vermeidens von Fehlerbedingungen in der Einschätzung von zusammengesetzten Ausdrücken zu.
• Die Fähigkeit dazu, potenziell unendliche Datenstrukturen zu bauen
• Die Fähigkeit dazu, Kontrollstrukturen als Abstraktionen statt als Primitive zu definieren.

Faule Einschätzung kann zur Verminderung des Speicherfußabdrucks führen, da Werte, wenn erforderlich, geschaffen werden. Jedoch, mit der faulen Einschätzung, ist es schwierig, sich mit befehlenden Eigenschaften wie das Ausnahme-Berühren und der Eingang/Produktion zu verbinden, weil die Ordnung von Operationen unbestimmt wird. Faule Einschätzung kann Raumleckstellen einführen. Außerdem das Beseitigen ist schwierig.

Das Gegenteil von faulen Handlungen ist eifrige Einschätzung, die manchmal als strenge Einschätzung bekannt ist. Eifriger Einschätzung wird als das auf Programmiersprachen verwendete Verzug-Verhalten allgemein geglaubt.

Geschichte

Faule Einschätzung wurde für die Lambda-Rechnung durch und für Programmiersprachen unabhängig durch eingeführt und.

Anwendungen

Verzögerte Einschätzung wird besonders auf funktionellen Sprachen verwendet. Wenn man verzögerte Einschätzung verwendet, wird ein Ausdruck nicht bewertet, sobald es zu einer Variable gebunden wird, aber wenn der Schätzer gezwungen wird, den Wert des Ausdrucks zu erzeugen. D. h. eine Behauptung solcher als (d. h. die Anweisung des Ergebnisses eines Ausdrucks zu einer Variable) fordert klar auf, dass der Ausdruck bewertet wird, und das Ergebnis in gelegt, aber was wirklich darin ist, ist irrelevant, bis es ein Bedürfnis nach seinem Wert über eine Verweisung auf in einem späteren Ausdruck gibt, dessen Einschätzung selbst aufgeschoben werden konnte, obwohl schließlich der schnell wachsende Baum von Abhängigkeiten beschnitten würde, um ein Symbol aber nicht einen anderen für die Außenwelt zu erzeugen, um zu sehen.

Einige Programmiersprachen verzögern Einschätzung von Ausdrücken standardmäßig, und einige andere stellen Funktionen oder spezielle Syntax zur Verfügung, um Einschätzung zu verzögern. In Miranda und Haskell wird die Einschätzung von Funktionsargumenten standardmäßig verzögert. Auf vielen anderen Sprachen kann Einschätzung durch das ausführliche Verschieben der Berechnung mit der speziellen Syntax (als mit dem Schema "" und "" und OCAML'S ""und"") oder, mehr allgemein, durch die Verpackung des Ausdrucks in einen thunk verzögert werden. Der Gegenstand, der solch eine ausführlich verzögerte Einschätzung vertritt, wird eine Zukunft oder Versprechung genannt. Perl 6 Gebrauch faule Einschätzung von Listen, so kann man unendliche Listen Variablen zuteilen und sie als Argumente für Funktionen verwenden, aber verschieden von Haskell und Miranda verwendet Perl 6 faule Einschätzung von arithmetischen Maschinenbedienern und Funktionen standardmäßig nicht.

Verzögerte Einschätzung ist im Vorteil des im Stande Seins, berechenbare unendliche Listen ohne unendliche Schleifen oder Größe-Sachen zu schaffen, die sich in der Berechnung einmischen. Zum Beispiel konnte man eine Funktion schaffen, die eine unendliche Liste schafft (häufig hat einen Strom genannt) Fibonacci-Zahlen. Die Berechnung der n-ten Fibonacci-Zahl würde bloß die Förderung dieses Elements von der unendlichen Liste sein, die Einschätzung nur der ersten n Mitglieder der Liste zwingend.

Zum Beispiel, in Haskell, kann die Liste aller Fibonacci-Zahlen als geschrieben werden:

Flunkereien = 0: 1: zipWith (+) Flunkereien (Schwanz-Flunkereien)

</Quelle>

In der Syntax von Haskell, "" prepends ein Element zu einer Liste, gibt eine Liste ohne sein erstes Element zurück, und verwendet eine angegebene Funktion (in diesem Fall Hinzufügung), um entsprechende Elemente von zwei Listen zu verbinden, um ein Drittel zu erzeugen.

Vorausgesetzt dass der Programmierer sorgfältig ist, werden nur die Werte, die erforderlich sind, ein besonderes Ergebnis zu erzeugen, bewertet. Jedoch können bestimmte Berechnungen auf das Programm hinauslaufen, das versucht, eine unendliche Zahl von Elementen zu bewerten; zum Beispiel würden die Anforderung der Länge der Liste oder das Versuchen, die Elemente der Liste mit einer Falte-Operation zu summieren, auf das Programm hinauslaufen entweder scheiternd, zu enden oder an Gedächtnis knapp werdend.

Kontrollstrukturen

Auf den meisten eifrigen Sprachen, wenn Behauptungen auf eine faule Mode bewerten.

wenn dann b sonst c

bewertet (a) dann, wenn, und nur wenn (a) zum wahren bewertet, tut, bewertet es (b), sonst bewertet es (c). D. h. entweder (b) oder (c) werden nicht bewertet. Umgekehrt auf einer eifrigen Sprache ist das erwartete Verhalten das

definieren Sie f (x, y) = 2*x

Satz k = f (e, 5)

wird noch (e) und (f) bewerten, wenn man (k) rechnen wird. Jedoch hängen benutzerbestimmte Kontrollstrukturen von genauer Syntax, so zum Beispiel ab

definieren Sie g (a, b, c) = wenn dann b sonst c

l = g (h, ich, j)

(i) und (j) würde beide auf einer eifrigen Sprache bewertet. Während in

l' = wenn h dann ich sonst j

(i) oder (j) würde bewertet, aber nie beide.

Faule Einschätzung erlaubt Kontrollstrukturen, normalerweise, und nicht als Primitive oder Übersetzungszeit-Techniken definiert zu werden. Wenn (i) oder (j) Nebenwirkungen haben oder Durchlaufzeit-Fehler einführen, können die feinen Unterschiede zwischen (l) und (l') kompliziert sein. Da die meisten Programmiersprachen Turing-abgeschlossen sind, ist es möglich, benutzerbestimmte faule Kontrollstrukturen auf eifrigen Sprachen als Funktionen einzuführen, obwohl sie von der Syntax der Sprache für die eifrige Einschätzung abweichen können: Häufig müssen die beteiligten Codekörper (wie (i) und (j)) in einen Funktionswert gewickelt werden, so dass sie, nur wenn genannt, durchgeführt werden.

Kurzschließen Sie Einschätzung von Kontrollstrukturen von Boolean wird manchmal "faul" genannt.

Das Arbeiten mit unendlichen Datenstrukturen

Muster der Liste der Erfolge

Anderer Gebrauch

In Computerfenstertechnik-Systemen wird die Malerei der Information zum Schirm durch gesteuert "stellen Ereignisse aus", die den Anzeigecode im letzten möglichen Moment steuern. Auf diese Weise vermeiden sie die Berechnung des unnötigen Anzeigeinhalts.

Ein anderes Beispiel der Indolenz in modernen Computersystemen ist copy-write Seitenzuteilung oder Nachfragepaginierung, wo Gedächtnis nur zugeteilt wird, wenn ein in diesem Gedächtnis versorgter Wert geändert wird.

Indolenz kann für hohe Leistungsdrehbücher nützlich sein. Ein Beispiel ist die Funktionalität von Unix mmap. mmap stellt "vertriebene Nachfrage" zur Verfügung, von Seiten von der Platte, so dass ladend

nur jene wirklich berührten Seiten werden ins Gedächtnis geladen, und unnötiges Gedächtnis wird nicht zugeteilt.

Indolenz auf eifrigen Sprachen

Pythonschlange:

In der Pythonschlange 2.x schätzt die Funktion eine Liste von ganzen Zahlen (eifrige oder unmittelbare Einschätzung):

>>> r = Reihe (10)

>>> drucken r

[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

>>> drucken r [3]

3

</Quelle>

In der Pythonschlange 3.x gibt die Funktion einen iterator zurück, der Elemente der Liste auf Verlangen (faule oder aufgeschobene Einschätzung) schätzt:

>>> r = Reihe (10)

>>> Druck (r)

Reihe (0, 10)

>>> Druck (r [3])

3</Quelle>

Die:This-Änderung zur faulen Einschätzung spart Ausführungszeit für große Reihen, in denen nie völlig Verweise angebracht werden darf und Speichergebrauch für große Reihen, wo nur ein oder einige Elemente jederzeit erforderlich sind.

:

Das Steuern der Begierde auf faulen Sprachen

Auf faulen Programmiersprachen wie Haskell, obwohl der Verzug Ausdrücke nur bewerten soll, wenn sie gefordert werden, ist es in einigen Fällen möglich, Code eifriger — oder umgekehrt zu machen, es fauler wieder zu machen, nachdem es eifriger gemacht worden ist. Das kann durch das ausführliche Codieren von etwas getan werden, was Einschätzung zwingt (der den Code eifriger machen kann) oder das Vermeiden solchen Codes (der den Code fauler machen kann). Strenge Einschätzung bezieht gewöhnlich Begierde ein, aber sie sind technisch verschiedene Konzepte.

Jedoch gibt es eine Optimierung, die in einigen Bearbeitern durchgeführt ist, genannt Strenge-Analyse, die in einigen Fällen dem Bearbeiter erlaubt abzuleiten, dass ein Wert immer verwendet wird. In solchen Fällen kann das die Wahl des Programmierers dessen machen, ob man diesen besonderen Wert oder nicht, irrelevant zwingt, weil Strenge-Analyse strenge Einschätzung zwingen wird.

In Haskell, strenge Konstrukteur-Felder kennzeichnend, bedeutet, dass ihre Werte immer sofort gefordert werden. Die Funktion kann auch verwendet werden, um einen Wert sofort zu fordern und dann ihn weiterzugeben, der nützlich ist, wenn ein Konstrukteur-Feld allgemein faul sein sollte. Jedoch führt keine dieser Techniken rekursive Strenge — dafür durch, eine genannte Funktion wurde erfunden.

Außerdem ist Muster, das in Haskell 98 zusammenpasst, standardmäßig streng, so muss der Qualifikator verwendet werden, um es faul zu machen.

Siehe auch

Logik von Combinatory

• Mit Currysoße zuzubereiten
• Dataflow
• Eifrige Einschätzung
• Funktionelle Programmierung
• Terminwaren und Versprechungen
• Die Graph-Verminderung
• Zusätzliche Computerwissenschaft - ein zusammenhängendes Konzept, wodurch Berechnung nur wiederholt wird, wenn sich ihre Eingänge ändern. Kann mit der faulen Einschätzung verbunden werden.
• Lambda-Rechnung
• Faule Initialisierung
• Lookahead
• Kurzschließen Sie (minimale) Einschätzung
• Nichtstrenge Programmiersprache
• Normale Ordnungseinschätzung

Zeichen

Weiterführende Literatur

• Doktorarbeit, die Universität Oxford

Designmuster

• John Hughes. "Warum funktionelle Programmiersachen". Die Computerzeitschrift - Sonderausgabe auf der faulen funktionellen Programmierung. Ausgabe 2 des Bands 32, April 1989.
• Philip Wadler. "Wie man Misserfolg durch eine Liste von Erfolgen eine Methode für das Ausnahme-Berühren, Zurückverfolgen und Muster ersetzt, das auf faulen funktionellen Sprachen zusammenpasst". Funktionelle Programmiersprachen und Computerarchitektur. Vortrag-Zeichen in der Informatik, 1985, Band 201/1985, 113-128.

Faulkeit auf strengen Sprachen

• Philip Wadler, Walid Taha und David MacQueen. "Wie man Indolenz zu einer strengen Sprache hinzufügt, ohne sogar seltsam zu sein". Werkstatt auf Normalem ML, Baltimore, September 1998.

Blog eilt durch Computerwissenschaftler dahin

• Robert Harper. "Der Punkt der Indolenz"
• Lennart Augustsson. "Mehr Punkte für die faule Einschätzung"

Links

• Faule Einschätzung am Portland Muster-Behältnis
• Faule Einschätzung an Haskell Wiki
• Die funktionelle Programmierung in der Pythonschlange wird fauler
• Faule Funktionsargument-Einschätzung auf der D Programmiersprache
• Faule Einschätzungsmakros in Nemerle
• Faule Programmierung und faule Einschätzung im Schema
• Lambda-Rechnung in Zunahme-Bibliotheken in C ++ Programmiersprache
• Faule Einschätzung in Perl