Ist Date.now referential transparent?

DateTime.Now oder Date.now ist referential transparent?

Dies ist eines der kontroversen Themen in einem Artikel über funktionale Programmierung in Qiita.

Zunächst müssen wir sehr vorsichtig sein, da das Wort "referential transparent" in gewissem Sinne ein heikles Wort / Konzept ist und eine prominente Diskussion in @ existier

Was ist referentielle Transparenz?

Der Fragesteller sagt:

Was bedeutet der Begriff referentielle Transparenz? Ich habe gehört, dass es als "es bedeutet, dass Sie Gleiche durch Gleiche ersetzen können" beschrieben wird, aber dies scheint eine unzureichende Erklärung zu sein.

Eine sehr typische Erklärung, aber die Idee, die typischerweise zu Missverständnissen führt, lautet wie folgt: (# 2 Antwort der obigen Seite von @Brian R. Bondy)

Referenzielle 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, in der Funktion wird kein externer Status verwendet.

Typische Behauptungen, die ich immer gehört und für falsch gehalten habe, lauten wie folgt:

In einer Programmiersprache,Date.now imme gibt ein @ zurüdifferent value das entspricht der aktuellen Zeit, und nach

Mit einer Funktion und einem Eingabewert erhalten Sie immer die gleiche Ausgabe.

deshalb,Date.now ist nicht referenziell transparent!

Ich weiß, dass einige (funktionierende) Programmierer fest davon überzeugt sind, dass der obige Anspruch vertrauenswürdig ist. Die Antworten 1 und 3 von @Uday Reddy erklären dies jedoch wie folgt:

ie Rede von "referentieller Transparenz", ohne die Unterscheidung zwischen L-Werten, R-Werten und anderen komplexen Objekten zu verstehen, die das konzeptuelle Universum des imperativen Programmierers bevölkern, ist grundsätzlich falsc

Die Vorstellung der funktionalen Programmierer von referentieller Transparenz scheint sich in drei Punkten vom Standardbegriff zu unterscheiden:

Wenn die Philosophen / Logiker Begriffe wie "Referenz", "Bezeichnung", "Designatum" und "Bedeutung" verwenden, verwenden funktionale Programmierer den Begriff "Wert". (Dies ist nicht ganz ihre Absicht. Ich stelle fest, dass Landin, Strachey und ihre Nachkommen auch den Begriff "Wert" verwendeten, um über Verweise / Bezeichnungen zu sprechen. Es mag nur eine terminologische Vereinfachung sein, die Landin und Strachey eingeführt haben, aber es scheint eine zu machen großer Unterschied bei naiver Verwendung.)

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

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

Come darüber nachzudenken, "externer Zustand" ist auch kniffliges Wort / Konzept.

Referenzielle 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, in der Funktion wird kein externer Status verwendet.

Ist "aktuelle Uhrzeit" "externer Zustand" oder "externer Wert"?

Wenn wir "aktuelle Zeit" als "externer Zustand" bezeichnen, wie wäre es dann mit "Mausereignis" ??

"mouse event" ist kein Zustand, der vom Programmierkontext verwaltet werden sollte, sondern einexternes Ereignis.

Mit einer Funktion und einem Eingabewert erhalten Sie immer die gleiche Ausgabe.

So können wir wie folgt verstehen:

"aktuelle Zeit" ist weder "Eingangswert" noch "externer Wert" noch "externer Zustand" undDate.now gibt immer die gleiche Ausgabe zurück, die dem laufenden Ereignis "aktuelle Zeit" entspricht.

Wenn man noch besteht oderwollen "aktuelle Zeit" als "Wert" aufrufen, nochmal

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

Der Wert von "aktuelle Uhrzeit" existiert nie in der Programmiersprache, sondern nur außerhalb von, und der Wert von "aktuelle Zeit" außerhalb wird offensichtlich über @ aktualisienicht der Programmierkontext, sondern der Zeitfluss der realen Welt.

Deshalb verstehe ich, dass Date.now referential transparent ist.

Ich würde gerne deine Idee lesen. Vielen Dank

EDIT1

ImWas ist (funktionale) reaktive Programmierung?

Conal Elliott @Conal erklärt auch Functional-Reactive-Programming (FRP).

r ist der erste, der FRP entwickelt, und erklärt dies s

ei @FRP geht es um - "Datentypen, die einen Wert im Zeitverlauf darstellen"

Dynamische / sich entwickelnde Werte (d. H. Werte "über die Zeit") sind an sich erstklassige Werte.

In dieser FRP-Perspektive,

Date kann als erstklassiger Wert "über die Zeit" betrachtet werden, der ein unveränderliches Objekt auf der Zeitachse ist.

.now ist eine Eigenschaft / Funktion zur Adressierung der "aktuellen Uhrzeit" innerhalb desDate

DeshalbDate.time gibt einen unveränderlichen und referenziellen transparenten Wert zurück, der unsere "aktuelle Zeit" darstellt.

EDIT2

(in JavaScript)

referenzielle intransparente Funktion

let a = 1;

let f = () => (a);

Eingabe vonFunction:f ist keine; Ausgabe vonFunction:f kommt drauf ana das hängt von einem Kontext außerhalb von @ f

referenzielle transparente Funktion

let t = Date.now();

let f = (Date) => (Date.now());

Obwohl,Date Wer wohnt in unserer physischen Welt,Date kann als unveränderlicher, erstklassiger FRP-Wert "über die Zeit" betrachtet werden.

Schon seitDate aus jedem Programmierkontext ist identisch, wir können in der Regel implizit weglassenDate als Eingabewert und einfach wie

let f = () => (Date.now());

EDIT3

atsächlich habe ich eine E-Mail an Conal Elliott @Conal gesendet, der einer der frühesten Entwickler von FRP ist. Er antwortete mir freundlich und teilte mir mit, dass es hier eine ähnliche Frage gibt.

Wie kann eine Zeitfunktion in der funktionalen Programmierung existieren?

Der Fragesteller sagt:

So ist meine Frage: Kann eine Zeitfunktion (die die aktuelle Zeit zurückgibt) in der funktionalen Programmierung existieren?

Wenn ja, wie kann es dann existieren? Verstößt es nicht gegen das Prinzip der funktionalen Programmierung? Es verletzt insbesondere die referenzielle Transparenz, die eine Eigenschaft der funktionalen Programmierung ist (wenn ich es richtig verstehe).

Oder wenn nein, wie kann man dann die aktuelle Zeit in der funktionalen Programmierung kennen?

und die Antwort von Conal Elliott @Conal im Stackoverflow:

Ja, es ist möglich, dass eine reine Funktion die Zeit zurückgibt, wenn sie diese Zeit als Parameter angibt. Unterschiedliches Zeitargument, unterschiedliches Zeitergebnis. Bilden Sie dann auch andere Funktionen der Zeit und kombinieren Sie sie mit einem einfachen Vokabular von Funktionen (-of-time) -transformierenden Funktionen (höherer Ordnung). Da der Ansatz zustandslos ist, kann die Zeit hier nicht diskret, sondern kontinuierlich (auflösungsunabhängig) sein, was die Modularität erheblich steigert. Diese Intuition ist die Grundlage für Functional Reactive Programming (FRP).

Edit4 Meine Wertschätzung für die Antwort von @Roman Sausarnes.

Bitte erlauben Sie mir, meine Perspektive für funktionale Programmierung und FRP vorzustellen.

Zunächst denke ich, dass es beim Programmieren im Wesentlichen um Mathematik geht, und das funktionale Programmieren verfolgt diesen Aspekt. Auf der anderen Seite ist das Imperative Programmieren eine Möglichkeit, Schritte des Maschinenbetriebs zu beschreiben, die nicht unbedingt Mathematik sind.

Pure funktionale Programmierung wie Haskel hat einige Schwierigkeiten, mit "state" oder IO umzugehen, und ich denke, das ganze Problem kommt von "time".

"Zustand" oder "Zeit" ist für uns eine ziemlich subjektive Entität, menschlich. Wir glauben natürlich, dass "Zeit" fließt oder vergeht und sich "Zustand" ändert, das heißt Naiver Realismus.

Ich denke, naiver Realismus für "Zeit" ist eine grundlegende Gefahr und ein Grund für all die Verwirrung in der Programmgemeinschaft, und nur wenige diskutieren diesen Aspekt. In der modernen Physik oder sogar in der Newton-Physik behandeln wir die Zeit auf rein mathematische Weise. Wenn wir also unsere Welt auf physikalische Weise überblicken, sollte es nicht schwierig sein, unsere Welt mit rein mathematischer funktionaler Programmierung zu behandel

So, ich überblicke unsere Welt / unser Universum ist unveränderlich wie eine bespielte DVD, und nur unsere subjektive Sichtweise ist veränderlich, einschließlich "Zeit" oder "Zustand".

In der Programmierung ist die einzige Verbindung zwischen dem unveränderlichen Universum und unserer veränderlichen subjektiven Erfahrung "Ereignis". Reine funktionale Programmiersprache wie Haskell hat diese Ansicht im Grunde genommen nicht, obwohl einige aufschlussreiche Forscher, darunter Cornel Elliott, FRP betreiben, aber die Mehrheit immer noch der Meinung ist, dass die FRP-Methode immer noch geringfügig oder schwer anzuwenden ist und viele von ihnen den veränderlichen Zustand als selbstverständlich betrachten.

Natürlich ist FRP die einzige clevere Lösung, und vor allem Cornel Elliott als Gründer hat diese philosophische Perspektive angewendet und erklärt -Erster Klassenwert "im Laufe der Zeit". Vielleicht würden leider viele Programmierer nicht verstehen, was er wirklich meinte, da sie vom naiven Realismus gefangen sind und es schwierig finden, zu sehen, dass "Zeit" eine philosophische oder physikalisch unveränderliche Einheit is

Also, wenn sie diskutieren "pure functional" oder "referenzielle Transparenz "Zum Vorteil der mathematischen Integrität / Konsistenz ist" Date.now "für mich natürlich referenziell transparent innerhalb der reinen funktionalen Programmierung, einfach weil" Date.time "auf einen bestimmten Punkt der unveränderlichen Zeitlinie des unveränderlichen Universums zugreift.

So was ist mitreferenzielle Transparenz in Denotational Semantik wie @Reddy oder @Roman Sausarnes diskutiert?

Ich habe einen Überblick über die referenzielle Transparenz in FP, insbesondere in der Haskell-Communit

Sicher, vielleicht könnte ich der aktualisierten Definition von "referentieller Transparenz" durch die Haskell-Community folgen und praktisch beurteilen wir, dass der Code mathematisch inkonsistent ist, wenn wir beurteilen, dass er nicht referentiell transparent ist, richtig?

Eigentlich wieder,

Wie kann eine Zeitfunktion in der funktionalen Programmierung existieren?

Ein Programmierer fragte wie folgt:

So ist meine Frage: Kann eine Zeitfunktion (die die aktuelle Zeit zurückgibt) in der funktionalen Programmierung existieren?

Wenn ja, wie kann es dann existieren? Verstößt es nicht gegen das Prinzip der funktionalen Programmierung? Es verletzt insbesondere die referenzielle Transparenz, die eine Eigenschaft der funktionalen Programmierung ist (wenn ich es richtig verstehe).

Oder wenn nein, wie kann man dann die aktuelle Zeit in der funktionalen Programmierung kennen?

Konsen

as Prinzip der funktionalen Programmierung verletz

= verletzt die referenzielle Transparenz, die eine Eigenschaft der funktionalen Programmierung ist

= Mathematisch inkonsistent !!

Das ist unsere gemeinsame Wahrnehmung, richtig?

In dieser Frage antworteten viele, dass "Funktion, die die aktuelle Zeit zurückgibt" nicht referenziell transparent ist, insbesondere in der Definition von "referenzieller Transparenz" durch die Haskell-Community, und viele erwähnten, dass es um mathematische Konsistenz geht.

Aber nur wenige haben geantwortet, dass "Funktion, die die aktuelle Zeit zurückgibt" referenziell transparent ist, und eine der Antworten stammt aus FRP-Sicht von Conal Elliott @ Conal.

IMO, FRP, eine Perspektive, um einen Zeitstrom als einen erstklassigen unveränderlichen Wert "über die Zeit" zu behandeln, ist eine korrekte Art und Weise mit mathematischen Prinzipien wie der Physik, wie ich oben erwähnt habe.

Wie kam es dann dazu, dass "Date.now" / "function returning the current time" durch den Haskell-Kontext intransparent wurde?

Nun, ich kann mir nur vorstellen, dass die aktualisierte Definition von "referentieller Transparenz" durch die Haskell-Community etwas falsch ist.

Ereignisgesteuerte & mathematische Integrität / Konsistenz

Ich erwähnte - In der Programmierung ist die einzige Verbindung zwischen dem unveränderlichen Universum und unserer veränderlichen subjektiven Erfahrung "Ereignis" oder "ereignisgesteuert".

Funktionale Programmierung wird ereignisgesteuert ausgewertet, Imperative Programmierung hingegen anhand der im Code beschriebenen Schritte / Routinen des Maschinenbetriebs.

"Date.now" hängt von "event" ab, und "event" ist im Kontext des Codes im Prinzip unbekannt.

Also, zerstört ereignisgesteuert die mathematische Integrität / Konsistenz? Absolut nicht

Mapping Syntax to Meaning - indexisch (Zeigefinger)

C.S. Peirce führte den Begriff „indexisch“ ein, um die Idee des Zeigens (wie in „Zeigefinger“) zu suggerieren.. ⟦I⟦, [[hier]], [[jetzt]], etc ..

Wahrscheinlich ist dies das mathematisch identische Konzept von "Monad", "functor" Dingen in Haskell. In der Denotationssemantik ist sogar in Haskell [[jetzt]] als 'Zeigefinger' klar.

Indexical (Zeigefinger) ist subjektiv, ebenso Event-driven

[[I]], [[hier]], [[jetzt]] usw. ist subjektiv, und auch in der Programmierung ist die einzige Verbindung zwischen dem unveränderlichen objektiven Universum und unserer veränderlichen subjektiven Erfahrung "Ereignis" oder " Ereignisgesteuert"

Daher, solange [[jetzt]] an die Ereignisdeklaration der "ereignisgesteuerten" Programmierung gebunden ist, tritt die subjektive (kontextabhängige) mathematische Inkonsistenz meiner Meinung nach nie auf.

Edit5

@ Bergi gab mir einen ausgezeichneten Kommentar:

Ja,Date.now, der externe Wert, ist referenziell transparent. Es bedeutet immer "aktuelle Zeit".

AberDate.now() ist nicht, es ist ein Funktionsaufruf, der je nach externem Status unterschiedliche Nummern zurückgibt. Das Problem mit dem referenziell transparenten "Konzept der aktuellen Zeit" ist, dass wir damit nichts berechnen können.

@ KenOKABE: Scheint der gleiche Fall zu sein wieDate.now(). Das Problem ist, dass dies nicht die aktuelle Zeit zur selben Zeit bedeutet, sondern zu unterschiedlichen Zeiten - die Ausführung eines Programms dauert einige Zeit, und dies macht es unrein.

Sicher, wir könnten eine referenziell transparenteDate.now function / getter, die immer den Zeitpunkt des Programmstarts zurückgibt (als ob eine Programmausführung unmittelbar wäre), aber so ist @ nicDate.now()/Date.Now Arbeit. Sie hängen vom Ausführungsstatus des Programms ab. - Bergi

ch denke, wir müssen darüber diskutiere

Date.now, der externe Wert, ist referenziell transparent.

[[Date.now]] ist, wie ich in # Edit4 erwähne, ein Index (Zeigefinger), der subjektiv ist, aber solange er im Indexbereich bleibt (ohne Ausführung / Auswertung), ist er referenziell transparent, worauf wir uns geeinigt haben.

Bergi schlägt jedoch @ vDate.now() (mit einer Ausführung / Auswertung) gibt zu verschiedenen Zeiten "verschiedene Werte" zurück, die nicht mehr referenziell transparent sind. Das haben wir nicht vereinbart.

Ich denke, dieses Problem hat er sicherlich gezeigt, existiert aber nur in Imperative Programming:

console.log(Date.now()); //some numeric for 2016/05/18 xx:xx:xx ....
console.log(Date.now()); //different numeric for 2016/05/18 xx:xx:xx ....

In diesem Fall,Date.now() ist nicht referenziell transparent, da stimme ich zu.

Im Paradigma der funktionalen Programmierung / deklarativen Programmierung würden wir jedoch niemals so schreiben. Wir müssen dies schreiben:

const f = () => (Date.now());

und dasf wird in einem "ereignisgesteuerten" Kontext ausgewertet. So verhält sich ein Functional-Programming-Code.

Ja,dieser Code ist identisch mit

const f = Date.now;

Daher ist im Paradigma der funktionalen Programmierung / deklarativen ProgrammierungDate.now oderDate.now() (mit einer Ausführung / Auswertung) hat nie Probleme, "verschiedene Werte" zu verschiedenen Zeiten zurückzugeben.

So wieder, wie ich in @ erwäh EDIT4, solange [[jetzt]] an die Ereignisdeklaration der "Ereignisgesteuerten" Programmierung gebunden ist, tritt die subjektive (kontextabhängige) mathematische Inkonsistenz meiner Meinung nach nie auf.