Implizite vs explizite Untertypisierung

Diese Seite behauptet das

Viele Sprachen verwenden keine implizite Subtypisierung (strukturelle Äquivalenz), sondern bevorzugen eine explizite / deklarierte Subtypisierung (Deklarationsäquivalenz).

Ich habe hauptsächlich Programmiersprachen verwendet, die explizite Untertypen verwenden . Was sind die Vorteile der impliziten Untertypisierung, wie in den obigen Anmerkungen beschrieben.

pl.programming-languages type-theory

— Frankie Ribéry
quelle

Aus der FAQ zum Umfang dieses Austauschs: "Die Arbeit in diesem Bereich zeichnet sich häufig durch die Betonung der mathematischen Technik und Genauigkeit aus." Ich stimme ab, weil ich in den Antworten auf diese Frage keinen Spielraum für Strenge sehe.

— David Eppstein

Leider gibt es bei der Beantwortung dieser Frage weitaus mehr Spielraum, als Sie sich zunächst erhoffen. Viele sehr angesehene Leute verbrannten in den 90er Jahren viel Ringen mit scheinbar trivialen Fragen zur Subtypisierung. Es ist leider ein Gebiet mit einem sehr schlechten Verhältnis von Aufwand zu Belohnung.

— Neel Krishnaswami

Ja, es gibt viel Raum für Mathematik und Genauigkeit bei der Beantwortung dieser Frage oder zumindest um mathematisch zu erklären, was implizite Subtypisierung ist . Ich bin mir nicht sicher, wie hoch das Verhältnis von Aufwand zu Belohnung ist.

— Noam Zeilberger

Ich hätte wahrscheinlich nur sagen sollen, dass es "sehr schwer" war, da ich nach Überlegung feststelle, dass ich sehr an den Antworten interessiert bin.

— Neel Krishnaswami

Ok, ich bin überzeugt. Ich würde meine Ablehnung entfernen, aber das System lässt mich nicht.

— David Eppstein

Antworten:

Die kurze Antwort lautet "um zusätzliche Eigenschaften des vorhandenen Codes zu überprüfen". Eine längere Antwort folgt.

Ich bin nicht sicher, ob "implizit" oder "explizit" eine gute Terminologie ist. Diese Unterscheidung wird manchmal als "strukturelle" oder "nominelle" Untertypisierung bezeichnet. Dann gibt es auch eine zweite Unterscheidung in den möglichen Interpretationen der strukturellen Untertypen (kurz beschrieben). Beachten Sie, dass alle drei Interpretationen der Untertypisierung tatsächlich orthogonal sind und es daher nicht wirklich sinnvoll ist, sie miteinander zu vergleichen, anstatt die Verwendung der beiden zu verstehen.

Die wichtigste operationale Unterscheidung bei der Interpretation einer strukturellen Subtypisierungsrelation A <: B besteht darin, ob sie von einem realen Zwang mit (Laufzeit- / Rechenzeit-) Recheninhalt oder vom Identitätszwang bezeugt werden kann. Wenn erstere die wichtige theoretische Eigenschaft ist, die gelten muss, ist "Kohärenz", dh wenn es mehrere Möglichkeiten gibt, zu zeigen, dass A ein substruktureller Subtyp von B ist, muss jeder der begleitenden Zwänge den gleichen Recheninhalt haben.

Der Link, den Sie angegeben haben, scheint die zweite Interpretation der strukturellen Untertypen zu haben, bei der A <: B durch Identitätszwang beobachtet werden kann. Dies wird manchmal als "Teilmengeninterpretation" von Untertypen bezeichnet, wobei die naive Ansicht vertreten wird, dass ein Typ eine Menge von Werten darstellt, und daher A <: B, nur für den Fall, dass jeder Wert von Typ A auch ein Wert von Typ B ist manchmal auch als "Verfeinerungstyp" bezeichnet, und eine gute Lektüre für die ursprüngliche Motivation sind die Verfeinerungstypen von Freeman & Pfenning für ML . Für eine neuere Inkarnation in F # können Sie Bengston et al., Verfeinerungstypen für sichere Implementierungen, lesen. Die Grundidee besteht darin, eine vorhandene Programmiersprache zu verwenden, die möglicherweise bereits über Typen verfügt (oder nicht), deren Typen jedoch nicht allzu viel garantieren (z. B. nur die Speichersicherheit), und eine zweite Ebene von Typen in Betracht zu ziehen, mit denen Teilmengen von Programmen ausgewählt werden zusätzliche, genauere Eigenschaften.

(Nun würde ich argumentieren, dass die mathematische Theorie hinter dieser Interpretation von Subtypisierung immer noch nicht so gut verstanden ist, wie sie sein sollte, und vielleicht deshalb, weil ihre Verwendung nicht so weit verbreitet ist, wie sie sein sollte. Ein Problem ist, dass die Menge von Werten "Die Interpretation von Typen ist zu naiv und wird daher manchmal eher aufgegeben als verfeinert. Ein weiteres Argument dafür, dass diese Interpretation der Subtypisierung mehr mathematische Aufmerksamkeit verdient, ist die Einführung zu Paul Taylors Subspaces in Abstract Stone Duality .)

— Noam Zeilberger
quelle

A \times B \times C <: A \times B

$A \times B \times C <: A \times B$

C

$C$

A

$A$

B

$B$

Es ist die Aufgabe des Optimierers, das optimale Speicherlayout herauszufinden, daher sollten Zwänge, die Identitäten sind, wirklich das Ergebnis der Optimierung sein.

— Andrej Bauer

Um Andrejs Kommentar zu meiner Antwort zu verdeutlichen, werden in einer Interpretation der Verfeinerungstypisierung Subtypisierungsbeziehungen immer per Definition durch Identitätszwang beobachtet , da die Verfeinerungstypen keinen zusätzlichen Recheninhalt enthalten. Mit anderen Worten, wenn A und B zwei Verfeinerungen ("Teilmengen" / "Eigenschaften") eines Wertetyps X sind, setzt A <: B für jeden Wert x in X fest, wenn x: A, dann auch x: B. Eine solche Aussage kann verifiziert oder verfälscht werden, hat aber zur Laufzeit keine Auswirkung, da die Beweise, dass x: A und x: B zur Laufzeit nicht existieren.

— Noam Zeilberger

N

$\mathbb{N}$

{x : N | x < 2^{32}}

$\{x:N\;\;|\;\;x < 2^{32}\}$

N

$N$

{x : N | x < 2^{32}}

$\{x:N | x < 2^{32}\}$

N

$N$

{x : N | x < 2^{32}}

$\{x:N | x < 2^{32}\}$

— Noam Zeilberger

Diese Antwort ist eine Art minimale Ergänzung zu Noams exzellenter Antwort. Ein interessanter Datenpunkt ist das Schicksal von C ++ - Konzepten, die auf dem Versuch beruhten, nominelle und strukturelle Typbegriffe zu vereinheitlichen.

Hier finden Sie eine hervorragende Zusammenfassung mit Links zu vielen relevanten Diskussionen: http://bartoszmilewski.wordpress.com/2010/06/24/c-concepts-a-postmortem/

In der obigen Beschreibung wird jedoch das nominale vs. strukturelle Problem in keiner Tiefe erörtert. Hier gibt es noch eine andere Beschreibung: http://nerdland.net/2009/07/alas-concepts-we-hardly-knew-ye/

Das Schlüsselpapier, auf das beide verweisen, ist Bjarne Stroustrups „Vereinfachung der Verwendung von Konzepten“: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2906.pdf , das im praktischen Teil behandelt wird Probleme in einiger Tiefe angetroffen.

Insgesamt ist die Diskussion eher pragmatisch als rigoros. Es gibt jedoch einen guten Einblick in die Art von Kompromissen, die mit diesen Problemen verbunden sind, insbesondere im Kontext einer großen vorhandenen Sprache.

— sclv
quelle