Kann Elementary Affine Logic als Kerntypsystem einer praktischen Programmiersprache verwendet werden?

Elementary Affine Logic ist ein Typsystem, das die Klasse der λ-Terme erfasst, die in der Elementarzeit reduziert werden können. Darüber hinaus können EAL-typisierbare Begriffe mithilfe des abstrakten Fragments des Lamping-Algorithmus reduziert werden, was für mich besonders interessant ist, da ich die entsprechenden Interaktionskombinatoren untersuche.

Meine Frage ist, wie kann man eine praktische Programmiersprache mit EAL als zugrunde liegendem Typsystem erstellen? Dh welche Art von Erweiterungen (Fixpunkte, Polymorphismus, abhängige Typen, Datentypen usw.) könnten für das Kerntypsystem vorgenommen werden, ohne diese Eigenschaft zu beeinflussen, und wäre eine solche Sprache in der Praxis verwendbar oder wäre sie es auch irgendwie restriktiv aus Gründen, die ich nicht kenne?

Etwas sehr Ähnliches, aber die Verwendung von Light Affine Logic (LAL) anstelle von EAL, wurde vor einigen Jahren von Baillot, Gaboardi und Mogbil versucht (das Papier finden Sie hier ). Ich denke, ihre Arbeit lässt sich leicht auf EAL übertragen, ein liberaleres System.

Was die Merkmale einer solchen Sprache betrifft, so haben Sie nativ Polymorphismus (EAL ist eine Einschränkung der linearen Logik zweiter Ordnung). Soweit ich weiß, hat sich niemand mit abhängigen Typen befasst, aber ich verstehe nicht, warum sie nicht funktionieren sollten. Tatsächlich funktioniert untypisierte EAL genauso gut wie typisierte EAL, da ihre Normalisierungseigenschaften nicht von Typen abhängen.

Eine Konsequenz ist, dass Sie in EAL beliebige Fixpunkte von Typen verwenden können (siehe zum Beispiel dieses andere Papier von Baillot) und Datentypen im natürlichen rekursiven Stil definieren können (wie ) zusammen mit der weniger natürlichen (aus Programmiersicht) System-F-Definition. Durch die obige Bemerkung zur untypisierten Normalisierung wird eine auf EAL basierende Programmiersprache jedoch immer vollständig sein$\mathtt{list\ A := nil\mathrel | A\ *\ list\ A}$Dies bedeutet, dass Sie keinen Fixpunktkombinator haben und die Verwendung rekursiver Typen nicht so natürlich ist, wie Sie es erwarten würden. Nehmen wir zum Beispiel Scott-Ziffern: Ohne rekursive Definitionen (vom Fixpunktkombinator angegeben) ist es schwierig, mit dieser Darstellung von ganzen Zahlen etwas auszudrücken, das über zeitkonstante Operationen hinausgeht. Daher müssen Sie weiterhin Church-Ziffern für die Iteration verwenden (dh ), mit deren Hilfe Sie die grundlegende Schichtungsbeschränkung der (die ihnen ihre Komplexitätseigenschaften verleiht): Sie können a nicht iterieren Funktion die selbst durch Iteration definiert wurde ( hier die Art der Ganzzahlen der Kirche).$\mathtt{for}$$\mathsf{Nat}\rightarrow\mathsf{Nat}$$\mathsf{Nat}$

Ein Beispiel: Mit einigen "Church Integer Hacking" ist es möglich, in EAL so zu definieren, dass ohne Iteration. Anschließend können Sie iterieren , um die Exponentialfunktion zu definieren , die jedoch selbst nicht iteriert werden kann. Unabhängig davon, welche Programmiersprache auf EAL basiert, muss ein Mechanismus vorhanden sein, der bestimmte Definitionen durch Iteration verbietet. Es ist schwer vorstellbar, dass eine solche Einschränkung nicht zu einer Sprache führen würde, die sich für den Programmierer unangenehm anfühlt. Wie auch immer, niemand verbietet dir zu versuchen, zu sehen, was du bekommen kannst!$\mathsf{dbl}:\mathsf{Nat}\rightarrow\mathsf{Nat}$$\mathsf{dbl}\ \underline{n} = \underline{2n}$ $\mathsf{dbl}$$\mathsf{exp}$

Wenn Sie an der Beziehung zwischen optimaler Bewertung, EAL und Lichtlogik im Allgemeinen interessiert sind, empfehlen wir Ihnen auf jeden Fall, sich Coppolas Arbeiten von Anfang bis Mitte der 2000er Jahre anzusehen .