functional-programming - pure - referential transparency




Was ist referenzielle Transparenz? (8)

Was bedeutet der Begriff referentielle Transparenz ? Ich habe es als "es bedeutet, dass man Gleiches durch Gleiches ersetzen kann" beschrieben, aber das scheint eine unzureichende Erklärung zu sein.


  1. Die Denotationssemantik basiert auf Modellierungssprachen, indem Domänen aufgebaut werden, die denierbare Werte darstellen .
  2. Funktionale Programmierer verwenden den Begriffswert, um die Konvergenz einer Berechnung auf der Grundlage der Neuschreibungsregeln der Sprache zu beschreiben, d. seine betriebliche Semantik.

In 1 gibt es eine Klarheit von zwei Sprachen in Frage:

  • der eine, der modelliert wird, die Objektsprache
  • die Sprache der Modellierung, die Metasprache

In 2 können sie dank der Nähe der Objekte und Metasprachen verwechselt werden.

Als Sprachumsetzer finde ich, dass ich mich ständig an diese Unterscheidung erinnern muss.

Also Prof. Reddy darf ich euch so paraphrasieren :-)

Im Kontext von funktionaler Programmierung und Semantik ist der Begriff referentielle Transparenz nicht referentiell transparent.


Beachten Sie, dass dieses Konzept der "Bedeutung" etwas ist, das im Kopf des Beobachters geschieht. So kann die gleiche "Referenz" verschiedene Dinge für verschiedene Menschen bedeuten. So haben wir zum Beispiel eine Disambiguierungsseite von Edinburgh in Wikipedia.

Ein verwandtes Problem, das im Zusammenhang mit der Programmierung auftreten kann, könnte Polymorphismus sein.

Und vielleicht sollten wir einen Namen für den Sonderfall des Polymorphismus (oder vielleicht sogar Castings) haben, wo für unsere Zwecke die verschiedenen polymorphen Fälle semantisch äquivalent sind (im Gegensatz dazu, nur ähnlich zu sein. Zum Beispiel die Zahl 1 - die repräsentiert sein könnte) die Verwendung eines Integer-Typs oder eines komplexen Typs oder einer Vielzahl anderer Typen - kann polymorph behandelt werden.


Ein Ausdruck ist referenziell transparent, wenn er durch seinen Wert ersetzt werden kann, ohne den Algorithmus zu ändern, was zu einem Algorithmus führt, der die gleichen Effekte hat und am selben Eingang ausgegeben wird.


Eine referentiell transparente Funktion ist eine, die wie eine mathematische Funktion wirkt; Bei den gleichen Eingaben erzeugt es immer die gleichen Ausgaben. Es impliziert, dass der eingeführte Zustand nicht modifiziert wird und dass die Funktion keinen eigenen Zustand hat.


Für diejenigen, die eine knappe Erklärung benötigen, werde ich eine riskieren (aber lesen Sie die folgende Offenbarung).

Referentielle Transparenz in einer Programmiersprache fördert das Gleichzeitigkeitsdenken - je mehr referenzielle Transparenz Sie haben, desto einfacher ist es, die Argumentation zu begründen. ZB mit einer (Pseudo-) Funktionsdefinition,

fx = x + x,

Die Leichtigkeit, mit der Sie f (foo) mit foo + foo im Rahmen dieser Definition (sicher) ersetzen können, ohne zu viele Einschränkungen zu haben, wo Sie diese Reduktion durchführen können, ist ein guter Hinweis darauf, wie viel referentielle Transparenz Ihre Programmiersprache hat hat.

Zum Beispiel, wenn foo x ++ im Sinne von C-Programmierung wäre, dann könnten Sie diese Reduktion nicht sicher durchführen (das heißt, wenn Sie diese Reduktion durchführen würden, würden Sie nicht mit dem gleichen Programm enden, mit dem Sie begonnen haben).

In praktischen Programmiersprachen werden Sie keine perfekte referentielle Transparenz sehen, aber funktionale Programmierer kümmern sich mehr darum als die meisten (vgl. Haskell, wo es ein Kernziel ist).

(Vollständige Offenlegung: Ich bin ein funktionaler Programmierer, also sollten Sie diese Erklärung mit einer Prise Salz beantworten.)


Referentielle Transparenz, ein in der funktionalen Programmierung gebräuchlicher Begriff, bedeutet, dass Sie bei einer Funktion und einem Eingabewert immer die gleiche Ausgabe erhalten. Das heißt, dass in der Funktion kein externer Zustand verwendet wird.

Hier ist ein Beispiel für eine referentielle transparente Funktion:

int plusOne(int x)
{
  return x+1;
}

Mit einer referentiellen transparenten Funktion, die eine Eingabe und eine Funktion enthält, könnten Sie sie durch einen Wert ersetzen, anstatt die Funktion aufzurufen. Anstatt also plusOne mit einem Paramter von 5 zu benennen, könnten wir das einfach durch 6 ersetzen.

Ein anderes gutes Beispiel ist die Mathematik im Allgemeinen. Wenn in der Mathematik eine Funktion und ein Eingabewert angegeben wird, wird immer auf denselben Ausgabewert abgebildet. f (x) = x + 1. Daher sind Funktionen in der Mathematik referentiell transparent.

Dieses Konzept ist für Forscher wichtig, da es bedeutet, dass es bei einer referenziell transparenten Funktion für eine einfache automatische Parallelisierung und Zwischenspeicherung geeignet ist.

Referentielle Transparenz wird immer in funktionalen Sprachen wie Haskell verwendet.

-

Im Gegensatz dazu gibt es das Konzept der referentiellen Undurchsichtigkeit. Dies bedeutet das Gegenteil. Der Aufruf der Funktion erzeugt möglicherweise nicht immer die gleiche Ausgabe.

//global G
int G = 10;

int plusG(int x)
{//G can be modified externally returning different values.
  return x + G;
}

Ein anderes Beispiel ist eine Elementfunktion in einer objektorientierten Programmiersprache. Elementfunktionen arbeiten im Allgemeinen mit seinen Elementvariablen und sind daher referenziell opak. Mitgliederfunktionen können natürlich referentiell transparent sein.

Ein weiteres Beispiel ist eine Funktion, die aus einer Textdatei liest und die Ausgabe druckt. Diese externe Textdatei könnte sich jederzeit ändern, sodass die Funktion referenziell opak ist.


[Dies ist ein Postskriptum zu meiner Antwort vom 25. März, in dem Bemühen, die Diskussion den Anliegen der funktionalen / imperativen Programmierung näher zu bringen.]

Die Idee der referenziellen Transparenz der funktionalen Programmierer scheint sich auf dreierlei Weise vom Standardbegriff zu unterscheiden:

  • Während die Philosophen / Logiker Begriffe wie "Referenz", "Denotation", "Designatum" und " Bedeutung " verwenden, verwenden funktionale Programmierer den Begriff "Wert". (Das ist nicht ganz ihr Tun. Ich bemerke, dass Landin, Strachey und ihre Nachkommen auch den Begriff "Wert" benutzten, um über Referenz / Denotation zu reden. Es könnte nur eine terminologische Vereinfachung sein, die Landin und Strachey eingeführt haben, aber es scheint ein großer Unterschied, wenn sie auf naive Art benutzt werden.)

  • Funktionale Programmierer scheinen zu glauben, dass diese "Werte" innerhalb der Programmiersprache existieren, nicht außerhalb. Sie unterscheiden sich dabei sowohl von den Philosophen als auch von den Programmiersprachen-Semantikern.

  • Sie scheinen zu glauben, dass diese "Werte" durch Bewertung erhalten werden sollen.

Im Wikipedia-Artikel über referentielle Transparenz heißt es heute Morgen:

Ein Ausdruck wird als referenziell transparent bezeichnet, wenn er durch seinen Wert ersetzt werden kann, ohne das Verhalten eines Programms zu ändern (mit anderen Worten, ein Programm zu erzeugen, das die gleichen Auswirkungen hat und am selben Eingang ausgegeben wird).

Dies steht völlig im Widerspruch zu dem, was die Philosophen / Logiker sagen. Sie sagen, dass ein Kontext referenziell oder referenziell transparent ist, wenn ein Ausdruck in diesem Kontext durch einen anderen Ausdruck ersetzt werden kann , der sich auf dasselbe bezieht (ein coreferenzieller Ausdruck). Wer sind diese Philosophen / Logiker? Dazu gehören Frege , Russell , Whitehead , Carnap , Quine , Church und unzählige andere. Jeder von ihnen ist eine hoch aufragende Figur. Die vereinte intellektuelle Kraft dieser Logiker ist, um es milde auszudrücken, weltbewegend. Alle sind sich darin einig, dass Referenten / Denominationen außerhalb der formalen Sprache existieren und Ausdrücke in der Sprache nur über sie sprechen können. Alles, was man in der Sprache tun kann, ist, einen Ausdruck durch einen anderen Ausdruck zu ersetzen, der auf dasselbe Objekt verweist. Die Referenten / Bezeichnungen selbst existieren nicht innerhalb der Sprache. Warum weichen die Funktionsprogrammierer von dieser bewährten Tradition ab?

Man könnte annehmen, dass die Programmiersprachen-Semantiker sie in die Irre geführt haben könnten. Aber sie taten es nicht.

Landin :

(a) jeder Ausdruck hat eine verschachtelte Unterexpressionsstruktur, (b) jeder Unterausdruck bezeichnet etwas (normalerweise eine Zahl, einen Wahrheitswert oder eine numerische Funktion) , (c) das Ding, das ein Ausdruck bezeichnet, dh sein "Wert", hängt nur vom Werte seiner Unterausdrücke, nicht auf andere Eigenschaften von ihnen. [Betonung hinzugefügt]

Stoy :

Das einzige, was für einen Ausdruck von Bedeutung ist, ist sein Wert, und jeder Teilausdruck kann durch irgendeinen anderen Wert ersetzt werden [Hervorgehoben]. Außerdem ist der Wert eines Ausdrucks in gewissen Grenzen immer der gleiche, wenn er auftritt ".

Vogel und Wadler :

Der Wert eines Ausdrucks hängt nur von den Werten seiner konstituierenden Ausdrücke (falls vorhanden) ab, und diese Teilausdrücke können frei durch andere ersetzt werden, die den gleichen Wert besitzen [zusätzliche Hervorhebung].

Im Nachhinein waren die Bemühungen von Landin und Strachey, die Terminologie zu vereinfachen, indem "Referenz" / "Bezeichnung" durch "Wert" ersetzt wurde, möglicherweise unklug gewesen. Sobald man von einem "Wert" hört, besteht die Versuchung, an einen Bewertungsprozess zu denken, der dazu führt. Es ist ebenso verlockend, an das zu denken, was die Bewertung als "Wert" produziert, obwohl es ganz klar ist, dass dies nicht die Bezeichnung ist. Das ist das, was ich in den Augen funktionaler Programmierer dem Konzept der "referentiellen Transparenz" zugetraut habe. Aber der "Wert", von dem die frühen Semantiker gesprochen haben, ist nicht das Ergebnis einer Bewertung oder der Ausgabe einer Funktion oder dergleichen. Es ist die Bezeichnung des Begriffs.

Wenn wir einmal den sogenannten "Wert" eines Ausdrucks ("Referenz" oder "Denotation" im klassischen Philosophen-Diskurs) als komplexes mathematisch-konzeptionelles Objekt verstehen, eröffnen sich allerlei Möglichkeiten.

  • Strachey interpretierte Variablen in imperativen Programmiersprachen als L-Werte , wie in meiner Antwort vom 25. März erwähnt, die ein anspruchsvolles Begriffsobjekt ist, das keine direkte Repräsentation innerhalb der Syntax einer Programmiersprache hat.
  • Er interpretierte auch Befehle in solchen Sprachen als Zustand-zu-Zustand-Funktionen, eine weitere Instanz eines komplexen mathematischen Objekts, das kein "Wert" innerhalb der Syntax ist.
  • Selbst ein seitenwirksamer Funktionsaufruf in C hat einen wohldefinierten "Wert" als Zustandsübertrager, der Zustände zu Paaren von Zuständen und Werten abbildet (die sogenannte "Monade" in der Terminologie von funktionalen Programmierern).

Der Widerwille funktionaler Programmierer, solche Sprachen "referenziell transparent" zu nennen, impliziert lediglich, dass sie solche komplexen mathematischen / konzeptuellen Objekte nur ungern als "Werte" zulassen. Auf der anderen Seite scheinen sie durchaus bereit, einen staatlichen Transformator als "Wert" zu bezeichnen, wenn er in seine eigene Lieblingssyntax gesetzt und mit einem Schlagwort wie "Monade" verkleidet wird. Ich muss sagen, dass sie völlig widersprüchlich sind, auch wenn wir ihnen zugestehen, dass ihre Vorstellung von "referentieller Transparenz" eine gewisse Kohärenz hat.

Ein wenig Geschichte könnte Licht ins Dunkel bringen, wie diese Verwirrungen entstanden sind. Der Zeitraum zwischen 1962 und 1967 war für Christopher Strachey sehr intensiv. Zwischen 1962 und 1965 nahm er eine Teilzeitstelle als wissenschaftlicher Assistent bei Maurice Wilkes an, um die Programmiersprache zu entwickeln und zu implementieren, die später als CPL bekannt wurde. Dies war eine imperative Programmiersprache, sollte aber auch über leistungsfähige funktionale Programmiersprachen verfügen. Landin, der in seiner Beratungsfirma ein Angestellter von Strachey war, hatte großen Einfluss auf Stracheys Sicht der Programmiersprachen. In der bahnbrechenden Arbeit " Landin program- ming Landin " von 1965 fördert Landin unverblümt funktionale Programmiersprachen (nennt sie denotative Sprachen) und beschreibt imperative Programmiersprachen als ihre "Antithese". In der anschließenden Diskussion stellen wir fest, dass Strachey Zweifel an der starken Position von Landin aufkommen lässt.

... DLs bilden eine Teilmenge aller Sprachen. Sie sind eine interessante Teilmenge, aber eine, die unbequem zu verwenden ist, es sei denn, Sie sind daran gewöhnt. Wir brauchen sie, weil wir im Moment nicht wissen, wie man Beweise mit Sprachen erstellt, die Imperative und Sprünge enthalten. [Betonung hinzugefügt]

Im Jahr 1965 nahm Strachey die Position eines Lesers in Oxford ein und scheint im Wesentlichen Vollzeit an der Entwicklung einer Theorie der Imperative und Sprünge gearbeitet zu haben. 1967 war er bereit mit einer Theorie, die er in seinem Kurs " Grundlegende Konzepte in Programmiersprachen " in einer Sommerschule in Kopenhagen unterrichtete. Die Vorlesungsnotizen sollten veröffentlicht worden sein, aber "unglücklicherweise, wegen der langwierigen Bearbeitung, kam das Verfahren nie zustande; wie viele von Stracheys Arbeit in Oxford hatte die Zeitung jedoch eine einflussreiche private Zirkulation." ( Martin Campbell-Kelly )

Die Schwierigkeit, Stracheys Schriften zu erhalten, hätte dazu führen können, dass die Verwirrungen propagiert wurden, wobei sich die Menschen auf Sekundärquellen und Hörensagen stützen würden. Aber jetzt, da " Fundamental concepts " im Internet verfügbar sind, muss man nicht auf Ratespiele zurückgreifen. Wir sollten es lesen und uns überlegen, was Strachey meinte. Bestimmtes:

  • In Abschnitt 3.2 beschäftigt er sich mit "Ausdrücken", in denen er von "referenzieller R-Wert-Transparenz" spricht.
  • Sein Abschnitt 3.3 behandelt "Befehle", wo er von "L-Wert-referenzieller Transparenz" spricht.
  • In Abschnitt 3.4.5 spricht er von "Funktionen und Routinen" und erklärt, dass "jede Abweichung von referenzieller R-Wert-Transparenz in einem R-Wert-Kontext entweder durch Zerlegen des Ausdrucks in mehrere Befehle und einfachere Ausdrücke oder, falls das erweist sich als schwierig, das Thema eines Kommentars. "

Jede Rede von "referenzieller Transparenz", ohne die Unterscheidung zwischen L-Werten, R-Werten und anderen komplexen Objekten zu verstehen, die das konzeptionelle Universum des imperativen Programmierers bevölkern, ist fundamental falsch.


Der Begriff "referentielle Transparenz" kommt von der analytischen Philosophie , dem Zweig der Philosophie, der natürliche Sprachkonstrukte, Aussagen und Argumente analysiert, die auf den Methoden der Logik und Mathematik basieren. Mit anderen Worten, es ist das am nächsten kommende Fach außerhalb der Informatik zu dem, was wir Semantik der Programmiersprache nennen. Der Philosoph Quine war verantwortlich dafür, das Konzept der referentiellen Transparenz zu initiieren, aber es war auch implizit in den Ansätzen von Bertrand Russell und Alfred Whitehead.

Im Kern ist "referentielle Transparenz" eine sehr einfache und klare Idee. Der Begriff "Referent" wird in der analytischen Philosophie verwendet, um über das zu reden, worauf sich ein Ausdruck bezieht . Es ist in etwa dasselbe wie das, was wir mit "Bedeutung" oder "Denotation" in der Programmiersprachensemantik meinen. In Andrew Birketts Beispiel ( Blogpost ) bezieht sich der Begriff "die Hauptstadt von Schottland" auf die Stadt Edinburgh. Das ist ein einfaches Beispiel für einen "Referenten".

Ein Kontext in einem Satz ist "referenziell transparent", wenn das Ersetzen eines Begriffs in diesem Kontext durch einen anderen Begriff, der sich auf dasselbe Objekt bezieht, die Bedeutung nicht ändert. Beispielsweise

Das schottische Parlament trifft sich in der schottischen Hauptstadt.

bedeutet dasselbe wie

Das schottische Parlament tagt in Edinburgh.

Der Kontext "Das schottische Parlament trifft sich ..." ist also ein referentiell transparenter Kontext. Wir können "die Hauptstadt von Schottland" durch "Edinburgh" ersetzen, ohne die Bedeutung zu ändern. Um es anders auszudrücken, der Kontext interessiert sich nur dafür, worauf sich der Begriff bezieht und nichts anderes. In diesem Sinne ist der Kontext "referenziell transparent".

Auf der anderen Seite, in dem Satz,

Edinburgh ist seit 1999 die Hauptstadt Schottlands.

wir können solch einen Ersatz nicht machen. Wenn wir das täten, würden wir sagen: "Edinburgh ist seit 1999 Edinburgh", was eine verrückte Sache ist und nicht die gleiche Bedeutung wie der ursprüngliche Satz hat. So scheint es, dass der Kontext "Edinburgh ist seit 1999 ..." reflektorisch undurchsichtig ist (das Gegenteil von referentiell transparent). Es scheint sich um etwas mehr zu kümmern als das, worauf sich der Begriff bezieht. Was ist es?

Dinge wie die "Hauptstadt Schottlands" werden als bestimmte Begriffe bezeichnet, und sie haben Logikern und Philosophen lange Zeit keinen mageren Kopfschmerz gelassen. Russell und Quine haben sie aussortiert und gesagt, dass sie nicht wirklich "referenziell" sind, dh es ist ein Fehler zu glauben, dass die obigen Beispiele verwendet werden, um sich auf Entitäten zu beziehen. Der richtige Weg, den obigen Satz zu verstehen, ist zu sagen

Schottland hat seit 1999 eine Hauptstadt und diese Hauptstadt ist Edinburgh.

Dieser Satz kann nicht in einen nussartigen umgewandelt werden. Problem gelöst! Der Punkt von Quine war zu sagen, dass die natürliche Sprache chaotisch oder zumindest kompliziert ist, weil sie für den praktischen Gebrauch geeignet ist, aber Philosophen und Logiker sollten Klarheit schaffen, indem sie sie auf die richtige Weise verstehen. Referentielle Transparenz ist ein Werkzeug, mit dem solche Bedeutungsklarheit erreicht werden kann .

Was hat das alles mit der Programmierung zu tun? Eigentlich nicht viel. Wie wir bereits sagten, ist referenzielle Transparenz ein Werkzeug, das beim Verständnis von Sprache verwendet wird, dh bei der Zuweisung von Bedeutung . Christopher Strachey , der den Bereich der Programmiersprachensemantik begründet hat, benutzte ihn in seiner Sinnesforschung. Sein Grundlagenpapier " Grundlegende Konzepte in Programmiersprachen " ist im Internet verfügbar. Es ist ein schönes Papier und jeder kann es lesen und verstehen. Also, bitte tue es. Du wirst sehr erleuchtet sein. Er führt in diesem Absatz den Begriff "referentielle Transparenz" ein:

Eine der nützlichsten Eigenschaften von Ausdrücken ist die von Quine [4] referenzierte Transparenz. Im Wesentlichen bedeutet dies, dass, wenn wir den Wert eines Ausdrucks finden wollen, der einen Unterausdruck enthält, das einzige, was wir über den Unterausdruck wissen müssen, ist sein Wert. Alle anderen Merkmale des Unterausdrucks, wie seine interne Struktur, die Anzahl und Art seiner Komponenten, die Reihenfolge, in der sie ausgewertet werden, oder die Farbe der Tinte, in die sie geschrieben werden, sind für den Wert des Hauptelements irrelevant Ausdruck.

Die Verwendung von "im Wesentlichen" deutet darauf hin, dass Strachey es paraphrasiert, um es in einfachen Worten zu erklären. Funktionale Programmierer scheinen diesen Absatz auf ihre eigene Art zu verstehen. Es gibt 9 weitere Fälle von "referentieller Transparenz" in dem Papier, aber sie scheinen sich nicht um irgendeinen anderen zu kümmern. In der Tat ist das ganze Papier von Strachey der Erklärung der Bedeutung von imperativen Programmiersprachen gewidmet . Aber heute behaupten funktionale Programmierer, dass imperative Programmiersprachen nicht referenziell transparent sind. Strachey würde sich in seinem Grab drehen.

Wir können die Situation retten. Wir sagten, dass natürliche Sprache "chaotisch oder zumindest kompliziert" ist, weil sie praktisch für den praktischen Gebrauch gemacht wird. Programmiersprachen sind die gleichen. Sie sind "chaotisch oder zumindest kompliziert", weil sie für den praktischen Gebrauch geeignet sind. Das bedeutet nicht, dass sie uns verwirren müssen. Sie müssen nur richtig verstanden werden, indem wir eine metaphysische Sprache verwenden, die referentiell transparent ist, damit wir Klarheit in der Bedeutung haben. In dem von mir zitierten Papier macht Strachey genau das. Er erklärt die Bedeutung der imperativen Programmiersprachen, indem er sie in elementare Konzepte zerlegt und nirgends Klarheit verliert. Ein wichtiger Teil seiner Analyse besteht darin, darauf hinzuweisen, dass Variablen in Programmiersprachen zwei Arten von "Werten" haben, die als l-Werte und r-Werte bezeichnet werden . Vor Stracheys Papier wurde dies nicht verstanden, und Verwirrung herrschte vor. Heute erwähnt die Definition von C es routinemäßig und jeder C-Programmierer versteht die Unterscheidung. (Ob die Programmierer in anderen Sprachen es gleich gut verstehen, ist schwer zu sagen.)

Sowohl Quine als auch Strachey beschäftigten sich mit der Bedeutung von Sprachkonstruktionen, die eine Art von Kontextabhängigkeit beinhalten. Unser Beispiel "Edinburgh ist seit 1999 die Hauptstadt von Schottland" bedeutet beispielsweise, dass die "Hauptstadt Schottlands" von der Zeit abhängt, zu der sie in Betracht gezogen wird. Eine solche Kontextabhängigkeit ist sowohl in natürlichen Sprachen als auch in Programmiersprachen eine Realität. Selbst in der funktionalen Programmierung sind freie und gebundene Variablen in Bezug auf den Kontext zu interpretieren, in dem sie auftreten. Kontextabhängigkeit jeglicher Art blockiert die referentielle Transparenz in irgendeiner Weise. Wenn Sie versuchen, die Bedeutung von Begriffen ohne Rücksicht auf die Kontexte zu verstehen, von denen sie abhängen, würden Sie wieder mit Verwirrung enden. Quine beschäftigte sich mit der Bedeutung der modalen Logik. Er vertrat die Ansicht, dass die Modallogik referentiell opak ist und dass sie durch die Übersetzung in einen referenziell transparenten Rahmen (zB durch die Notwendigkeit der Beweisbarkeit) bereinigt werden sollte. Er hat diese Debatte weitgehend verloren. Logiker und Philosophen fanden Kripkes mögliche Weltsemantik vollkommen adäquat. Eine ähnliche Situation herrscht auch bei der imperativen Programmierung. Die von Strachey erklärte Abhängigkeit des Staates und die von Reynolds erklärte Speicherabhängigkeit (in Anlehnung an Kripkes mögliche Weltsemantik) sind vollkommen adäquat. Funktionale Programmierer wissen nicht viel von dieser Forschung. Ihre Ideen zur referentiellen Transparenz sind mit einem großen Körnchen Salz zu nehmen.

[Zusätzliche Anmerkung: Die obigen Beispiele zeigen, dass eine einfache Phrase wie "Hauptstadt von Schottland" mehrere Bedeutungsebenen hat. Auf einer Ebene könnten wir derzeit über die Hauptstadt sprechen. Auf einer anderen Ebene könnten wir über alle möglichen Hauptstädte sprechen, die Schottland im Laufe der Zeit gehabt haben könnte. Wir können in einen bestimmten Kontext "hineinzoomen" und "verkleinern", um alle Kontexte in der normalen Praxis ziemlich einfach zu überspannen. Die Effizienz der natürlichen Sprache nutzt unsere Fähigkeit dazu. Imperative Programmiersprachen sind auf sehr ähnliche Weise effizient. Wir können eine Variable x auf der rechten Seite einer Zuweisung (den r-Wert ) verwenden, um über ihren Wert in einem bestimmten Zustand zu sprechen. Oder wir könnten über seinen l-Wert sprechen, der alle Zustände umfasst. Menschen werden selten von solchen Dingen verwirrt. Sie können jedoch möglicherweise alle Bedeutungsschichten, die Sprachkonstrukten innewohnen, genau erklären. Alle diese Bedeutungsschichten sind nicht notwendigerweise "offensichtlich" und es ist eine Frage der Wissenschaft, sie richtig zu studieren. Die Unartikulation gewöhnlicher Menschen, solche überlagerten Bedeutungen zu erklären, bedeutet jedoch nicht, dass sie verwirrt sind.]

Ein getrenntes "Postscript" unten verbindet diese Diskussion mit den Anliegen der funktionalen und imperativen Programmierung .





referential-transparency