Zusätzlich zu dem, was Willem geschrieben hat, können Sie immer write_canonical/1 verwenden, um die kanonische Darstellung eines Begriffs zu erhalten.
Zum Beispiel in Ihrem Fall:
%Vor% Dies löst die Aufgabe und zeigt, dass Sie die Liste [[]] korrekt erweitert haben.
Insbesondere haben wir:
%Vor% Das stimmt: Dies ist eine Liste mit einem einzelnen Element, das [] ist, wie durch das erste Argument des '.'/2 -Begriffs angegeben. Da es sich um das only -Element handelt, ist das zweite Argument auch [] .
Nun, das ./2 ist das, was in Lisp als cons bekannt ist. Es enthält zwei Parameter: ein Kopf das Element und einen Schwanz . Der Tail kann die leere Liste [] oder eine andere cons sein.
Sehen wir uns zuerst den Begriff an, den wir konvertieren müssen:
%Vor%Was wir sehen, ist eine äußere Liste mit zwei Elementen (wir werden diese Elemente vorerst ignorieren). Das heißt also, wir haben eine Struktur wie:
%Vor% Jetzt müssen wir natürlich noch Item1 und Item2 ausfüllen. Item2 ist nicht schwer: Es ist die leere Liste [] so:
Item1 dagegen ist eine Liste mit einem Element, also lautet die Struktur:
Mit Item11 das Element dieser Unterliste. Dieser Gegenstand ist fruits , also bedeutet das:
Wenn wir alle zusammensetzen, erhalten wir:
%Vor% Wenn wir dies in GNU-Prolog ( gprolog ) eingeben, erhalten wir:
gprolog kann somit ein Werkzeug zur Überprüfung sein, da es die Punktnotation in den syntaktischen Zucker für eine Liste umwandelt.
Ursprünglich in Prolog gab es keine [] und die vector wurde immer mit dem . erstellt.
Hier ist ein Beispiel aus einem Papier von 1979 von David Warren [* 36'footnote]:
%Vor%Testen und Demonstrieren ...
%Vor%Das obige funktioniert in yap, eclipse, gprolog, xsb. Es funktioniert jedoch nicht in swipl (siehe Anhang).
concatenated wie in der Arbeit dargestellt ist genau das gleiche wie die typische moderne Prolog-Implementierung von append , aber mit einem anderen Namen und einem anderen Marker für das Ende.
Das allgemeine Muster besteht darin, dass jedes Element über den . von seinem Nachbarn getrennt ist.
Das letzte Element ist eine Markierung, um das Ende anzuzeigen. In Warrens Beispiel ist nil der Marker, der das Ende anzeigt. Die Verwendung von nil scheint eine Konvention, aber keine Anforderung zu sein. Nachfolgende Entwicklungen in Prolog ersetzten die Verwendung von nil als Marker für das Ende mit der Verwendung von [] als Marker für das Ende.
Warrens bahnbrechendes Beispiel kann minimal umgeschrieben werden, um [] anstelle von nil ...
Warren fährt fort ...
... wo eine Liste entweder das Atom 'nil' oder ein aus dem binärer Funktor wessen zweites Argument ist eine Liste ... wir schreiben das Funktor als
rechts-assoziativer Infixoperator, so dass z Beispiel, die erste erwähnte Liste [ed:(a.b.c.d.nil)] ist entspricht der Standardform.(a,.(b,.(c,.(d,nil))))'
Warren liefert dieses Beispiel ...
%Vor%Testen und Demonstrieren ...
%Vor% Diese Implementierung von (list(L)) , jetzt vor 40 Jahren,
entspricht nicht den modernen Erwartungen eines "logischen" Programms ...
... Ich weiß nicht, wie ich diese Probleme beheben soll.
Wenn Warren schreibt ...
Wir schreiben den Funktor als
rechts -assoziativer Infix-Operator, so dass ...
... Ich denke, er bezieht sich auf dieses eigenartige und nützliche Merkmal des Prologs xfy ...
Es ist vernünftig zu erwarten, dass sich der Operator yfx umgekehrt verhält;
während xfy erlaubt Elemente von links zu greifen und den Rest nach rechts zu ignorieren,
vielleicht yfx ermöglicht es Ihnen, Elemente von rechts zu greifen und den Rest nach links zu ignorieren ...
[* 36'footnote] --- Ссылка
Versuchen Sie nicht, in swipl mit . oder [] zu spielen,
weder die . noch die [] funktionieren wie beschrieben.
Ich habe einen Fehler gemeldet, um über . zu blättern;
Annahme der Nichtübereinstimmung mit traditionellem
und Standardprologsysteme waren von Interesse;
es scheint, dass es nicht ist.
Der Autor von swipl macht den Vorschlag, term_expansion zu verwenden, jedoch kann weder die Verwendung von term_expansion noch von goal_expansion das Problem beheben
folgenden grundlegenden Kompatibilitätsproblemen.
... schlage ich vor, dass der Autor von swipl den prolog vielleicht nicht sehr gut kennt (term_expansion?! ??!) oder nicht an Prologkonformität interessiert ist oder daran interessiert ist, ein vendor lock-in zu etablieren.