Re: Declaring a local dynamic variable?

["Pascal J. Bourguignon" <pjb@informatimago.com>]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> Let's memorize Stefan's remark as a starting-point to work-on:
>
> " But if d1 and d2 are in two separate packages that know
> nothing about each other but who happen to call each other through some
> potentially twisted sequence of calls, they will still interfere,
> because there's only (globally) one dynamic variable by that name."
>
> Would like to see such a twisted sequence and what makes it's different from a common bug.


With (setq lexical-binding nil).

Here is a case where it's a common bug:

;; --------

(defun p1-f ()
  (let ((print-circle t))
    (p2-g (function p1-h) '#1=(1 2 . #1#))))

(defun p1-h (data f)
  (print data)
  (funcall f))

;; --------

(defun p2-g (p d)
  (let ((print-circle nil))
    (funcall p '(1 2 3) (function p2-i))))

(defun p2-i (data)
  (print data))

;; --------



Here is a case where it's not a common bug:

;; --------

(defun p1-f ()
  (let ((be-careful t))
    (p2-g (function p1-h) '#1=(1 2 . #1#))))

(defun p1-h (data f)
  (if be-careful
    (let ((print-circle t)) (print data))
    (print data))
  (funcall f))

;; --------

(defun p2-g (p d)
  (let ((be-careful nil))
    (funcall p '(1 2 3) (function p2-i))))

(defun p2-i (data)
  (if be-careful
    (let ((print-circle t)) (print data))
    (print data)))

;; --------


The difference is that in the first case, there's a global definition
for print-circle, while in the second case, the packages expect
be-careful to be local special variables.   You could use my macros and
(declare (special be-careful)) in each package, and the bug would
persist.  

However, it would NOT occur in Common Lisp, where you'd have (in-package
"P1") and (in-package "P2") forms in front of each bodies of code,
because you'd have actually TWO special symbols: p1::be-careful and
p2::be-careful.




The conclusion is that in emacs lisp you have to prefix ALL the symbols!
Which clearly demonstrates a failure of the language.

-- 
__Pascal Bourguignon__
http://www.informatimago.com/