Curry Howard Korrespondenz mit Predicate Logic?

Also versuche ich, mich um Curry-Howard zu kümmern. (Ich habe es mehrmals versucht, es ist einfach nicht gelierend / scheint zu abstrakt). Um etwas Konkretes anzugehen, arbeite ich an einigen Haskell-Tutorials, die von Wikipedia verlinkt sind, insbesondere von Tim Newsham . Es gibt auch eine nützliche Diskussion, wenn Newsham das Tutorial veröffentlicht.

(Aber ich werde die dataWrapper von Newsham und Piponi ignorieren und über die zugrunde liegenden Typen sprechen.) Wir haben Hilberts Axiomschema (ausgedrückt als S , K- Kombinatoren); wir haben Sätze als Typen; Implikation als Funktionspfeil; und Modus Ponens als Funktionsanwendung:

axK :: p -> q -> p
axK  = const
axS :: (p -> q -> r) -> (p -> q) -> p -> r
axS     f                g          x  = f x (g x)

modPons = ($);   infixl 0 `modPons`          -- infix Left, cp ($) is Right

Dann kann ich das Identitätsgesetz ableiten:

ident     = axS `modPons` axK `modPons` axK  -- (S K K)
-- ident :: p -> p                           -- inferred

Diese Typen als bloße Typevars zu haben, die lediglich Aussagen entsprechen, scheint eher einfallslos. Kann ich mehr vom Typsystem verwenden, um die Sätze tatsächlich zu konstruieren? Ich denke:

data      IsNat n  = IsNat !n                -- [Note **]

data      Z        = Z
axNatZ ::            IsNat Z
axNatZ             = IsNat Z

data      S n      = S !n
axNatS :: IsNat n -> IsNat (S n)
axNatS   (IsNat n) = IsNat (S n) 

twoIsNat = axNatS `modPons` (axNatS `modPons` axNatZ)
-- ===> IsNat (S (S Z))

[Anmerkung **] Ich verwende strenge Konstruktoren gemäß dem Diskussionsthread, um die Einführung von _ | _ zu vermeiden .

Wo:

• IsNat ist ein Prädikat: einen Satz aus einem Begriff machen.
• n ist eine Variable.
• S ist eine Funktion, die aus einer Variablen einen Term macht.
• Z ist eine Konstante (niladische Funktion).

Ich habe also eine eingebettete Prädikatenlogik (erster Ordnung) (?)

Ich schätze, dass meine Typen nicht sehr hygienisch sind; Ich könnte leicht einen Typevar-als-Satz mit einem Typevar-als-Begriff verwechseln. Vielleicht sollte ich das KindSystem verwenden, um sie zu trennen. OTOH, meine Axiome müssten spektakulär falsch sein, um zu einer Schlussfolgerung zu gelangen.

Ich habe nicht ausgedrückt:

• universeller Quantifizierer: Es ist implizit für die freien Vars;
• existentielle Quantität: In der Tat könnten Konstanten als skolemisierte Existentiale wirken;
• Gleichheit der Begriffe: Ich habe wiederholte Typevars in Implikationen verwendet;
• Beziehungen: Das scheint zu funktionieren, oder ist es Verwirrung? ...

    data          PlusNat n m l  = PlusNat !n !m !l

    axPlusNatZ :: IsNat m       -> PlusNat Z m m
    axPlusNatZ   (IsNat m)       = PlusNat Z m m

    axPlusNatS :: PlusNat n m l -> PlusNat (S n) m (S l)
    axPlusNatS   (PlusNat n m l) = PlusNat (S n) m (S l)

    plus123 = axPlusNatS `modPons`
              (axPlusNatZ `modPons`
               (axNatS `modPons` (axNatS `modPons` axNatZ)) ) 
    -- ===> PlusNat (S Z) (S (S Z)) (S (S (S Z)))

Das Schreiben der Axiome ist einfach, mit freundlicher Genehmigung von Wadlers Theorems for Free! . Die Beweise zu schreiben ist harte Arbeit. (Ich werde die modPonsFunktion fallen lassen und nur die Funktionsanwendung verwenden.)

Erreicht dies tatsächlich eine Logik? Oder ist es verrücktes Zeug? Soll ich aufhören, bevor ich meinem Gehirn mehr Schaden zufüge?

Sie sollten abhängige Typen benötigen, um FOPL in Curry-Howard auszudrücken. Aber ich scheine das nicht zu tun (?)

Um zu erklären, warum ich mich mit Newshams und (besonders) Piponis dataWrappern unwohl fühle ... (Dies wird mehr eine Frage als eine Antwort sein, aber vielleicht hilft es zu erklären, was mit meinem falsch ist IsNat, obwohl es Newsham sehr ähnlich zu sein scheint. )

Piponi Seite 17 hat:

data Proposition = Proposition :-> Proposition
                  | Symbol String
                  | False deriving Eq

data Proof = MP Proof Proof
     | Axiom String Proposition deriving Eq

Ich sehe hier keine Typen. Wenn Sie einen Datenkonstruktor buchstabieren, :->funktioniert er nicht als Funktionspfeil. Wenn Sie einen Datenkonstruktor MP(für Modus Ponens) buchstabieren , funktioniert er nicht als Anwendung. Es gibt einen 'intelligenten Konstruktor'-Operator (@@)für MP, der jedoch keine Funktion anwendet: Er führt lediglich einen Mustervergleich für den :->Konstruktor durch.

Newsham hat (ich beginne mit dem Implikationsabschnitt / Modus Ponens):

data Prop p = Prop p

data p :=> q = Imp (Prop p -> Prop q)

impInj :: (Prop p -> Prop q) -> Prop (p :=> q)
impInj p2q = Prop (Imp p2q)

impElim :: Prop p -> Prop (p :=> q) -> Prop q
impElim p (Prop (Imp p2q)) = p2q p

Das sieht eher so aus: Wir haben Typen, Funktionspfeile, Funktionsanwendungen in impElim. Der Typkonstruktor Impmit seinen Injektions- und Eliminierungsregeln spiegelt die Beweisbaumstrukturen in den Lectures on Curry-Howard-Isomorphismus wider . Aber ich bin nervös: Warum braucht Impman einen Typkonstruktor und einen Datenkonstruktor? Auch hier macht die Rechtschreibung as :=>keinen Funktionspfeil. Warum all diese PropKonstruktoren zum Ein- und Auspacken ? Warum nicht einfach Prop (p -> q)?

Wenn ich mir also den Abschnitt "Konjunktion" anschaue (der eigentlich an erster Stelle steht):

data p :/\ q = And (Prop p) (Prop q)

andInj :: Prop p -> Prop q -> Prop (p :/\ q)
andInj p q = Prop (And p q)

andElimL :: Prop (p :/\ q) -> Prop p
andElimL (Prop (And p q)) = p

andElimR :: Prop (p :/\ q) -> Prop q
andElimR (Prop (And p q)) = q

Diese ElimFunktionen verwenden keine Funktionsanwendung. Sie stimmen lediglich mit den Konstruktoren überein. Es gibt keine implizite Struktur für die Konjunktion: Wir verlassen uns ausschließlich darauf, dass der 'Programmierer' nur die andInjRegel verwendet hat, um einen Typ zu erstellen (p :/\ q).

Wenn Newsham zur Kommutativität der Konjunktion kommt:

commuteAnd :: Prop (p :/\ q) -> Prop (q :/\ p)
commuteAnd pq = andInj (andElimR pq) (andElimL pq)

Und behauptet

Beachten Sie, dass unser Haskell-Proof keinen Verweis auf die interne Struktur des Datentyps (: / \) enthielt. Nachdem wir unsere Regeln "andInj", "andElimR" und "andElimL" definiert und bewiesen haben, sollten wir nie wieder einen Blick in die Implementierung des Datentyps (: / \) werfen müssen.

Ich bin einfach anderer Meinung:

• Die Signatur für commuteAnd hängt von der internen Struktur des :/\Typkonstruktors ab.
• Obwohl die Funktionsdefinition sieht lediglich Funktionsanwendung mag in der Tat die andElims tun „Peek“ in die Struktur.

Ich würde erwarten, dass wir die Kommutativität der Konjunktion anhand ihrer Definition beweisen können, ohne ein Axiom zu benötigen, um dies zu sagen (?)

OK, wenn ich so puristisch bin, was erwarte ich dann? Diese Konjunktion basiert auf der Kodierung der Kirche für Paare:

type Conj p q r = Prop ((p -> q -> r) -> r)     -- not right, see later

andInj :: Prop p -> Prop q -> Conj p q r
andInj (Prop p) (Prop q) = Prop (\elim -> elim p q)

andElimL :: Conj p q p -> Prop p
andElimL (Prop conj) = Prop (conj axK)    -- axK is `const`

Jetzt kann ich commuteAndmit der 'richtigen' Funktionsanwendung schreiben :

--  commuteAnd :: (Conj p q r) -> (Conj q p r)
commuteAnd pq = andInj (andElimR pq) (andElimL pq)

Diese Funktionsdefinition ist dieselbe wie die von Newsham. Aber ich habe die Signatur auskommentiert, weil der abgeleitete Typ von GHC nicht allgemein genug ist. Es will Prop ((p -> p -> p) -> p) -> ((p -> p -> p) -> p). Welches ist nur eine ausgefallene Variation des Identitätsgesetzes.

Bearbeiten: (Nach @DerekElkins erstem Kommentar hier.) Verschrotte alles:

Ich bin in tiefem (und trübem) Wasser gelandet. Ich denke, mein Typ für Conjmuss polymorpher sein, möglicherweise Impredicative. Ich habe mich über den Versuch lustig gemacht, einen Typ mit höherem Rang zu vergeben:

type Conj p q = Prop (forall r.((p -> q -> r) -> r))

Aber GHC spielt nicht. (Und die Unterstützung für Impredicative Polymorphism ist "schuppig".) Und eine forallsolche quantifizierte Sache sieht verdächtig aus wie die Definition für Falsch / unbewohnt, die ich erwartet hatte.

Ich brauche einen höherrangigen Typ, aber keinen Impredicative. Und nicht auf den Typ für, Conjsondern fürcommuteAnd

commuteAnd :: (forall r. Conj p q r) -> (Conj q p r')
-- (same function for `commuteAnd` as above)

OK. Ich kann gerne ad infinitum Argumente austauschen.

[Ende der Bearbeitung]

Meine Frage: Wenn es legitim ist, was Newsham mit Verschachtelungskonstruktoren und Mustervergleich überall macht, was ist dann nicht legitim an meinem IsNatund Mustervergleich?