Lisp Klammer Frage

Die LABELS in

hat die Syntax labels ((function-name lambda-list [[local-declaration* | local-documentation]] local-form*)*) declaration* form* , daher müssen Sie eine Liste der lokalen Funktionsdefinitionen angeben, damit es funktioniert.

Da diese lokalen Funktionsdefinitionen selbst geklammert sind, müssen Sie labels eine Liste dieser Struktur übergeben: ((fun1 (...) ...) (fun2 (...) ...) ...) .

Leider sind Stack-Trace und Fehlermeldung nicht sehr hilfreich, um den Fehler hier zu erkennen, da die Nachricht nicht mitteilt, dass das Problem mit labels auftritt, und auch nicht im Trace. Die 4: (CCL::NX1-LABELS ... wäre ein Hinweis (Debugger-Puffer auf meinem lokalen Rechner).

Sehen Sie sich die Dokumentation für labels in der Hyperspec an, um mehr zu erfahren.

In anderen Sprachen, nicht Lisps, werden Klammern normalerweise zum Gruppieren von Operatoren verwendet und sind daher in vielen Fällen optional. Aber in Lisp Klammern sind immer sinnvoll. Es darf nicht extra oder optionale Klammer sein.

Die meisten Klammern um den Ausdruck bedeuten Funktion oder Makroanwendung :

In einem solchen Fall können zwei Klammern am Anfang des Ausdrucks auftreten, zum Beispiel , wenn das erste Element des Ausdrucks ein anderer Ausdruck ist, der zu einer Funktion selbst ausgewertet wird . Stellen Sie sich zum Beispiel die Funktion make-adder vor, die eine Zahl übernimmt und eine andere Funktion mit partiell angelegter Addition zurückgibt (übrigens, es ist ein Beispiel für currying ):

Wir können die Funktionsvariable increment auf diese Weise erstellen und sie dann auf die Variable anwenden:

aber wir können es auch direkt aufrufen (ok, das funktioniert nicht in Common Lisp, aber die gleiche Syntax funktioniert in anderen Lisps, genannt " Lisp-1 ", also ich glaube es ist es wert, es hier zu erwähnen):

mache am Anfang doppelte Klammern. Und natürlich sind beide Klammern obligatorisch.

Und ein letzter Fall, der Ihre Situation beschreibt, ist, wenn das Sprach- oder Benutzermakro Liste von Listen für seine Zwecke verwendet (erinnern Sie sich noch, das Lisp-Programm) ist selbst eine Liste von Listen von Ausdrücken?). Zum Beispiel weiß defun , dass das erste Argument ein Symbol und das zweite Argument eine Liste sein muss. Und labels macro weiß, dass das erste Argument eine Liste von Definitionen sein muss, von denen jede eine Liste selbst ist . Es wurde gemacht, um es dem Benutzer zu ermöglichen, mehr als ein Label gleichzeitig zu definieren:

Sie können also sehen, dass jede Klammer etwas bedeutet und Sie sie nicht alleine fallen lassen können.

Wie @danlei sagte, muss es eine Liste mit Funktionsdefinitionen im ersten Teil eines let / labels / flet geben. Wenn es ein einzelnes Element ist, dann enden Sie mit diesen überflüssigen Doppelklammern.

Tatsächlich gibt es ein paar Orte, an denen Panthesis in Lisp "unnatürlich" sind. Normalerweise sind die Regeln sehr konsistent: Eine Klammer startet eine Liste und das erste Element einer Liste ist die Funktion, die mit allen verbleibenden Listenelementen als Parameter verwendet wird. Diese Konsistenz wird auch für die meisten Makros und Spezialformen beibehalten und dies macht Lisp-Code sehr einheitlich ... aber in einigen Makro- und Sonderoperatoren Klammern haben eine andere Bedeutung und werden für die Gruppierung verwendet ... zum Beispiel

in diesem Fall ist zum Beispiel x in der ersten Panthese NICHT die Funktion, die mit L als Argument übergeben wird. Ein anderes Beispiel ist

In diesem Fall werden Klammern nur zum Gruppieren verwendet und das erste Element (x 10) ist eindeutig nicht die anzuwendende Funktion, noch ist das erste Element x eine Funktion.

labels funktioniert genau wie let und die scheinbar "extra" Klammer wird für die Gruppierung benötigt, falls mehr als eine Funktion definiert ist.

Während diese speziellen Fälle in der Tat etwas nervig sind, sind sie sehr wenige und nach dem Schreiben einiger Mengen von Lisp-Code werden Sie sie internalisieren und Sie werden sie einfach ohne nachzudenken bekommen.

Sie sind nichtsdestotrotz Asymmetrien, die zum Beispiel ziemlich schwer machen, einen korrekten Code-Walker zu schreiben, und auch oft, wenn Sie in diesem "Syntax-Bereich" von Lisp einen Fehler machen, ist die Fehlermeldung leider nicht wirklich hilfreich Fehler.

Diese "Komplexität" ist natürlich nichts im Vergleich zu anderen Sprachen (und fangen wir nicht an zu diskutieren, wie klar Nachrichten sind, wenn Sie in einer C ++ - Vorlage einen Fehler machen ;-)).

Ich denke, das ist nicht ganz richtig, dass die Lisp-Syntax "trivial" oder gar nicht vorhanden ist. Die Lisp-Syntax ist auch dann vorhanden, wenn sie nicht auf Zeichenebene, sondern auf Lisp-Formularebene ist, und sie ist fast trivial, mit Ausnahme einer Handvoll spezieller Formulare und Makros.