Sorry, I cant let you get away with this. :-) We were talking about DEFVAR. I like your example, but it should look like this: (defvar x 3) (defun f (g) (let ((x 2)) (funcall g))) (let ((x 1)) (f #'(lambda () x))) now this works correctly in elisp and common lisp and this would be more like what I would expect lots of elisp code to look. Although I would imagine that people dont code in this way normally since it would be a bear to debug in a complex module. -Reggie P.S. Please forgive the [application/ms-tnef]. Our company has been forced to use exchange and I havent coerced Microsoft OutHouse to do the correct thing yet. -----Original Message----- From: sperber(a)informatik.uni-tuebingen.de [mailto:sperber＠informatik.uni-tuebingen.de] Sent: Friday, July 03, 1998 5:25 AM To: xemacs-beta(a)xemacs.org Subject: Re: Where do you want to go tomorrow? Hrvoje> sperber(a)Informatik.Uni-Tuebingen.De (Michael Sperber [Mr. Preprocessor]) writes: work Hrvoje> It has been discussed multiple times in the past. In fact, it would Hrvoje> have already been done if the fate hadn't transpired against Chuck and Hrvoje> Ben working on XEmacs. Hrvoje> Can you explain what you mean by incompatible? Old code will obviously not run under the new Elisp engine, because it may intrinsically use dynamic binding for non-DEFVAR'ed names. New code will not run under the old engine because that does not support static binding, even if it syntactically is totally acceptable to the old engine. Also, the Elisp compiler does not reliably detect which variables should be DEFVAR'ed which aren't already. Consider the following program fragment which has different semantics depending on the interpretation of LET: (defun f (g) (let ((x 2)) (funcall g))) (let ((x 1)) (f #'(lambda () x))) ... and watch what sort of (bogus) message the compiler produces. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla