Wie Leben mit Emacs Lisp dynamische scoping?

So schlimm ist es nicht.

Die wichtigsten Probleme erscheinen können, mit 'freier Variablen in Funktionen.

(defun foo (a)
  (* a b))

In der obigen Funktion a ist eine lokale variable. b ist eine freie variable. In einem system mit dynamischer Bindung wie Emacs-Lisp, b gesucht bei runtime. Es gibt nun drei Fälle:

1. b ist nicht definiert -> Fehler
2. b ist eine lokale variable gebunden, die durch einige function call in der aktuellen dynamischen Geltungsbereich -> nehmen, dass der Wert
3. b ist eine Globale variable -> nehmen, dass der Wert

Die Probleme können dann sein:

• einem gebundenen Wert (global oder lokal) ist überschattet von einem Funktionsaufruf, möglicherweise unerwünschte
• eine Undefinierte variable ist NICHT beschattet -> Fehler auf Zugang
• eine Globale variable ist NICHT beschattet -> nimmt der Globale Wert, die möglicherweise unerwünschte

In ein Lisp mit einem compiler kompilieren der oben genannten Funktion könnte generieren eine Warnung, dass es eine freie variable. In der Regel Common Lisp-Compiler tun. Ein Dolmetscher wird nicht, die Warnung, man will einfach sehen, die Auswirkungen zur Laufzeit.

Beratung:

• stellen Sie sicher, dass Sie nicht mit freien Variablen versehentlich
• stellen Sie sicher, dass Globale Variablen haben einen speziellen Namen, so dass Sie sind leicht zu erkennen im Quellcode, in der Regel *foo-var*

Nicht schreiben

(defun foo (a b)
   ...
   (setq c (* a b))  ; where c is a free variable
   ...)

Schreiben:

(defun foo (a b)
   ...
   (let ((c (* a b)))
     ...)
   ...)

Binde alle Variablen, die Sie verwenden möchten, und Sie wollen sicherstellen, dass Sie nicht gebunden sind woanders.

Das ist im Grunde es.

Da GNU Emacs version 24 lexikalische Bindung unterstützt Emacs Lisp. Siehe: Lexikalische Bindung, GNU Emacs Lisp Reference Manual.

Zusätzlich zu den im letzten Absatz von Gilles Antwort, hier ist, wie RMS argumentiert zu Gunsten des dynamischen scoping in ein erweiterbares system:

Einige Sprache, die Designer glauben, dass
dynamische Bindung vermieden werden sollte, und
explizite argument übergeben werden soll
stattdessen verwendet. Vorstellen, dass die Funktion Ein
bindet die variable FOO und ruft die
Funktion B, die die Funktion aufruft
C, und C setzt den Wert von FOO.
Angeblich sollten übergeben Sie den Wert als
ein argument, das B, das sollte es passieren
als argument für C.

Dies nicht in eine erweiterbare
system jedoch, weil der Autor von
das system kann nicht wissen, was alle
Parameter werden. Sich vorstellen, dass die
Funktionen A und C sind Teil eines Benutzer
Erweiterung, während B ist Teil der
standard-system. Die variable FOO hat
nicht vorhanden in der standard-system; es
ist Teil der Erweiterung. Verwenden
explizite argument übergeben würde
benötigen Sie ein neues argument zu B,
was bedeutet umschreiben B und alles
das nennt B. In der häufigste Fall,
B ist der editor command dispatcher
loop, das heißt von einer schrecklichen
Anzahl der stellen.

Was noch schlimmer ist, C muss auch weitergegeben werden, eine
ein zusätzliches argument. B nicht zu finden
zu C name C nicht existieren, wenn B
geschrieben wurde). Es wohl findet
Zeiger auf C in der dispatch Befehl
Tabelle. Dies bedeutet, dass der gleiche Anruf
die manchmal ruft C könnte ebenso
auch rufen jedes editor-Kommando
definition. So mit der Bearbeitung
Befehle umgeschrieben werden müssen, zu akzeptieren
und ignorieren Sie das zusätzliche argument. Durch
nun, keiner von das original-system ist
Links!

Persönlich denke ich, dass wenn es ein problem mit Emacs-Lisp, es ist nicht dynamische scoping per se, aber es ist der Standard, und, dass es nicht möglich ist, zu erreichen, lexical scoping, ohne auf Erweiterungen. In der CL, dynamische und lexikalische scoping verwendet werden kann, und-mit Ausnahme der obersten Ebene (das ist also von mehreren deflex-Implementierungen), Global und erklärt spezielle Variablen -- der Standard ist lexikalisches scoping. In Clojure, zu, Sie können sowohl lexikalische und dynamischen scoping.

Zitieren RMS wieder:

Ist es nicht notwendig, für den dynamischen Bereich in der Regel nur im Rahmen zur Verfügung gestellt, einfach nur nützlich
für Sie zur Verfügung steht.

Erste, elisp hat getrennte variable und Funktion-Bindungen, so einige Fallstricke des dynamischen scoping nicht relevant sind.

Zweitens, können Sie immer noch setq zu setzen, Variablen, sondern den Wert nicht überleben Ausgang der dynamische Umfang es getan wird. Dies ist nicht grundsätzlich Verschieden von lexikalischen scoping, mit dem Unterschied, dass mit dynamic scoping eine setq in eine Funktion, die Sie aufrufen können Auswirkungen auf den Wert, den Sie sehen nach dem Aufruf der Funktion.

Gibt es lexical-let, ein makro, das (im wesentlichen) imitiert lexikalische Bindungen (ich glaube, es tut dies, indem Sie zu Fuß den Körper und ändern Sie alle vorkommen der lexikalisch Variablen lassen sich zu einer gensymmed Namen, schließlich uninterning dem symbol), wenn Sie absolut müssen.

Ich würde sagen, "code schreiben als normal". Es gibt Zeiten, wenn die dynamische Natur von elisp wird dich beißen, aber ich habe festgestellt, dass in der Praxis erstaunlich selten.

Hier ist ein Beispiel, was ich sagen über setq und dynamisch gebundene Variablen (bewertete kürzlich in einem nahe gelegenen Kratzer Puffer):

(let ((a nil))
  (list (let ((a nil))
          (setq a 'value)
          a)
        a))

(value nil)

Dynamische und lexikalische scoping-haben unterschiedliche Verhaltensweisen, wenn Sie ein Stück code in einem anderen Bereich als dem es definiert wurde. In der Praxis gibt es zwei Muster, die für die meisten beschwerlichen Fällen:

• Funktion Schatten eine Globale variable, dann ruft eine andere Funktion verwendet, die Globale variable.

  (defvar x 3)
  (defun foo ()
    x)
  (defun bar (x)
    (+ (foo) x))
  (bar 0) ⇒ 0

  Diese kommen nicht oft in Emacs, weil die lokalen Variablen, neigen zu kurzen Namen (oft einzige-Wort) in der Erwägung, dass Globale Variablen dazu neigen, zu lange Namen haben (oft mit dem Präfix packagename-). Viele standard-Funktionen haben Namen, die zu verlockend sind, um den Einsatz als lokale Variablen wie list und point, aber Funktionen und Variablen, die live im eigenen Namen Räume sind lokal Funktionen sind nicht sehr Häufig verwendet.

• Einer Funktion definiert ist, in einem lexikalischen Kontext und außerhalb dieser lexikalischen Kontext, weil es an eine übergeordnete Funktion.

  (let ((cl-y 10))
    (mapcar* (lambda (elt) (* cl-y elt)) '(1 2 3)))
  ⇒ (10 20 30)
  (let ((cl-x 10))
    (mapcar* (lambda (elt) (* cl-x elt)) '(1 2 3)))
  ⇑ (wrong-type-argument number-or-marker-p (1 2 3))

  Den Fehler aufgrund der Verwendung von cl-x als Variablen-Namen in der mapcar* (aus der cl - Paket). Beachten Sie, dass die cl Paket verwendet werden cl- als Präfix auch für seine lokalen Variablen in higher-order-Funktionen. Dies funktioniert auch Recht gut, in der Praxis, wie lange, wie Sie kümmern sich nicht um die gleiche variable verwenden, als einen globalen Namen und einen lokalen Namen zu, und Sie brauchen nicht zu schreiben Sie eine rekursive higher-order-Funktion.

P. S. Emacs Lisp Alter ist nicht der einzige Grund, warum es dynamisch scoped. Stimmt, in diesen Tagen, lisps tendenziell hin zu dynamischen scoping — Scheme und Common Lisp hatte nicht wirklich noch. Aber dynamischen scoping ist auch eine Bereicherung in einer Sprache, die gezielt zur Erweiterung eines Systems dynamisch: Sie können Haken in mehr Orte ohne besonderen Aufwand. Mit großer macht kommt große Seil an sich Aufhängen: Sie riskieren, versehentlich Einhaken in einen Ort, den Sie nicht kannte.

Ich völlig das Gefühl, Ihre Schmerzen. Ich finde das fehlen der lexikalischen Bindung in emacs eher nervig - vor allem nicht in der Lage, verwenden lexikalische Verschlüsse, das scheint zu sein, eine Lösung, die ich denke, eine Menge, kommen aus der neueren Sprachen.

Während ich habe keine weitere Beratung zu arbeiten, um die fehlenden features, die die vorherigen Antworten nicht decken, doch, ich möchte an dieser Stelle aus der Existenz eines emacs-Zweig namens `lexbind', die Umsetzung lexikalische Bindung in einer rückwärts-kompatiblen Art und Weise. In meiner Erfahrung lexikalische Verschlüsse sind noch ein wenig buggy in einigen Fällen, aber der Zweig scheint ein vielversprechender Ansatz zu sein.