Lexical binding

Lexical binding

[Stefan Monnier]

Just a note that the lexbind branch has been merged into trunk,


        Stefan

Re: Lexical binding

[David De La Harpe Golden]

On 01/04/11 18:32, Stefan Monnier wrote:
> Just a note that the lexbind branch has been merged into trunk,

wow, very cool... waaaiiit...

;;; -*- lexical-binding: t -*-
(defun april-fools? ()
   (let ((a t)
         (check (let ((a nil)) (lambda () a))))
     (funcall check)))

(april-fools?) => nil

This is great news.

Re: Lexical binding

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 01 Apr 2011 13:32:29 -0400
> 
> Just a note that the lexbind branch has been merged into trunk,

Congrats.

Re: Lexical binding

[Stefan Monnier]

>> Just a note that the lexbind branch has been merged into trunk,
> Congrats.

BTW: while I did a fair bit of work in the last few months to get this
branch to a state that I find good enough with a minimum of impact to
the existing code base, the congratulations should mostly go to Miles.
He started the effort, got it close to a pretty good state, and then
kept it up-to-date for many years.  Also Igor Kuzmin who wrote the
closure conversion code (which replaced some of Miles's original code;
sorry Miles but I think the result is a lot easier to
maintain/debug/improve) was an important contributor.


        Stefan

Re: Lexical binding

[Daniel Colascione]

On 4/1/2011 10:32 AM, Stefan Monnier wrote:
    ^^^^^^^^^^^^^^^^^

You couldn't wait just one more day? :-)

 > Just a note that the lexbind branch has been merged into trunk,

Congratulations.  This is great news.  Now let's get everything under 
lisp/ compiling with lexbind, wait a few releases for the ecosystem to 
stabilize, and rip out (null dynamic-binding) binding support. :)

cedet-bzr build failure (was : Lexical binding)

[Darren Hoo]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Just a note that the lexbind branch has been merged into trunk,

fail to build cedet-bzr after this merge

Debugger entered--Lisp error: 
(wrong-type-argument listp "Forgot to expand macro eieio-object-p")

Re: cedet-bzr build failure (was : Lexical binding)

[David Engster]

Darren Hoo writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Just a note that the lexbind branch has been merged into trunk,
>
> fail to build cedet-bzr after this merge
>
> Debugger entered--Lisp error: 
> (wrong-type-argument listp "Forgot to expand macro eieio-object-p")

Inside the cedet-bzr directory, try 'make clean-all' and compile again.

-David

Re: cedet-bzr build failure (was : Lexical binding)

[Darren Hoo]

David Engster <deng@randomsample.de> writes:

>> fail to build cedet-bzr after this merge
>>
>> Debugger entered--Lisp error: 
>> (wrong-type-argument listp "Forgot to expand macro eieio-object-p")
>
> Inside the cedet-bzr directory, try 'make clean-all' and compile again.
>
hmm, so there are changes in eieio.el in this merge, after I steal the
changes and applied to cedet-bzr, eieio.el now builds successfully, 

But then I got another error:

In toplevel form:
semantic-grammar-wy.el:169:12:Error: Wrong type argument: listp, "Forgot
to expand macro backquote-list*"

Re: cedet-bzr build failure (was : Lexical binding)

[David Engster]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

Darren Hoo writes:
> David Engster <deng@randomsample.de> writes:
>
>>> fail to build cedet-bzr after this merge
>>>
>>> Debugger entered--Lisp error: 
>>> (wrong-type-argument listp "Forgot to expand macro eieio-object-p")
>>
>> Inside the cedet-bzr directory, try 'make clean-all' and compile again.
>>
> hmm, so there are changes in eieio.el in this merge, after I steal the
> changes and applied to cedet-bzr, eieio.el now builds successfully, 
>
> But then I got another error:
>
> In toplevel form:
> semantic-grammar-wy.el:169:12:Error: Wrong type argument: listp, "Forgot
> to expand macro backquote-list*"

Yes, you're right. There was also a change to wisent-comp.el
(revno. 100595.1.31; you'll have to use "bzr log -n0" to see it).

I attached the patch with the changes for eieio.el and wisent-comp.el to
this mail. Eric, do you see a problem with committing those? I also
tested compilation with Emacs versions 23 and 22, and it seems to work
fine.

-David


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: cedet-lexbind.patch --]
[-- Type: text/x-patch, Size: 1664 bytes --]

=== modified file 'eieio/eieio.el'
--- eieio/eieio.el	2011-01-27 20:42:06 +0000
+++ eieio/eieio.el	2011-04-02 12:29:01 +0000
@@ -1207,7 +1207,7 @@
   (let ((byte-compile-free-references nil)
 	(byte-compile-warnings nil)
 	)
-    (byte-compile-lambda
+    (byte-compile
      `(lambda (&rest local-args)
 	,doc-string
 	;; This is a cool cheat.  Usually we need to look up in the

=== modified file 'semantic/wisent/wisent-comp.el'
--- semantic/wisent/wisent-comp.el	2010-04-09 02:08:59 +0000
+++ semantic/wisent/wisent-comp.el	2011-04-02 12:32:40 +0000
@@ -3500,9 +3500,19 @@
   ;; automaton internal data structure.  Then, because the internal
   ;; data structure contains an obarray, convert it to a lisp form so
   ;; it can be byte-compiled.
-  (byte-compile-form (wisent-automaton-lisp-form (eval form))))
+  (byte-compile-form
+   ;; FIXME: we macroexpand here since `byte-compile-form' expects
+   ;; macroexpanded code, but that's just a workaround: for lexical-binding
+   ;; the lisp form should have to pass through closure-conversion and
+   ;; `wisent-byte-compile-grammar' is called much too late for that.
+   ;; Why isn't this `wisent-automaton-lisp-form' performed at
+   ;; macroexpansion time?  --Stef
+   (macroexpand-all
+    (wisent-automaton-lisp-form (eval form)))))
 
-;;;###autoload
+;; FIXME: We shouldn't use a `byte-compile' handler.  Maybe using a hash-table
+;; instead of an obarray would work around the problem that obarrays
+;; aren't printable.  Then (put 'wisent-compile-grammar 'side-effect-free t).
 (put 'wisent-compile-grammar 'byte-compile 'wisent-byte-compile-grammar)
 
 (defun wisent-automaton-lisp-form (automaton)

Re: cedet-bzr build failure (was : Lexical binding)

[Eric M. Ludlam]

Hi David,

Thanks for looking into all that.  Your changes seem good to me.

Eric

On 04/02/2011 08:40 AM, David Engster wrote:
> Darren Hoo writes:
>> David Engster<deng@randomsample.de>  writes:
>>
>>>> fail to build cedet-bzr after this merge
>>>>
>>>> Debugger entered--Lisp error:
>>>> (wrong-type-argument listp "Forgot to expand macro eieio-object-p")
>>>
>>> Inside the cedet-bzr directory, try 'make clean-all' and compile again.
>>>
>> hmm, so there are changes in eieio.el in this merge, after I steal the
>> changes and applied to cedet-bzr, eieio.el now builds successfully,
>>
>> But then I got another error:
>>
>> In toplevel form:
>> semantic-grammar-wy.el:169:12:Error: Wrong type argument: listp, "Forgot
>> to expand macro backquote-list*"
>
> Yes, you're right. There was also a change to wisent-comp.el
> (revno. 100595.1.31; you'll have to use "bzr log -n0" to see it).
>
> I attached the patch with the changes for eieio.el and wisent-comp.el to
> this mail. Eric, do you see a problem with committing those? I also
> tested compilation with Emacs versions 23 and 22, and it seems to work
> fine.
>
> -David
>

Re: cedet-bzr build failure

[David Engster]

Eric M. Ludlam writes:
> Thanks for looking into all that.  Your changes seem good to me.

OK, I've pushed those changes to cedet-bzr.

-David

Re: cedet-bzr build failure (was : Lexical binding)

[Darren Hoo]

Hi David

On Sat, Apr 2, 2011 at 8:40 PM, David Engster <deng@randomsample.de> wrote:
> Yes, you're right. There was also a change to wisent-comp.el
> (revno. 100595.1.31; you'll have to use "bzr log -n0" to see it).
Good.

> I attached the patch with the changes for eieio.el and wisent-comp.el to
> this mail. Eric, do you see a problem with committing those? I also
> tested compilation with Emacs versions 23 and 22, and it seems to work
> fine.

I tested your patch with emacs 24 trunk, it builds ok and works fine for me.

BTW, what's the status of  CEDET merge currently? I don't track the file-rename
branch.

Sorry to bring up this again, But I really hope  that someday I can track only
the Emacs trunk and not to find anything missing in CEDET for day-to-day use.

Re: Lexical binding

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 01 Apr 2011 13:32:29 -0400
> 
> Just a note that the lexbind branch has been merged into trunk,

I see these when I bootstrap after "bzr up" (on Windows):

  Compiling D:/gnu/bzr/emacs/trunk/lisp/files.el
  In toplevel form:
  D:/gnu/bzr/emacs/trunk/lisp/files.el:2242:1:Error: Lisp nesting exceeds `max-lisp-eval-depth'
  Compiling D:/gnu/bzr/emacs/trunk/lisp/filesets.el
  In toplevel form:
  D:/gnu/bzr/emacs/trunk/lisp/filesets.el:1612:1:Error: Lisp nesting exceeds `max-lisp-eval-depth'
  Compiling D:/gnu/bzr/emacs/trunk/lisp/startup.el
  In toplevel form:
  D:/gnu/bzr/emacs/trunk/lisp/startup.el:1295:1:Error: Lisp nesting exceeds `max-lisp-eval-depth'

And later:

  make[1]: *** No rule to make target `../lisp/files.elc', needed by `DOC'.  Stop.

I worked around that by compiling these 3 files by hand using a
pre-lexbind Emacs binary.  Then the bootstrap ran to completion.

Strangely enough, once Emacs with lexbind is built, it has no problems
compiling these 3 files.

Does anyone else see this (on Windows or elsewhere)?

Re: Lexical binding

[Juanma Barranquero]

On Fri, Apr 1, 2011 at 22:42, Eli Zaretskii <eliz@gnu.org> wrote:

>  Compiling D:/gnu/bzr/emacs/trunk/lisp/files.el
>  In toplevel form:
>  D:/gnu/bzr/emacs/trunk/lisp/files.el:2242:1:Error: Lisp nesting exceeds `max-lisp-eval-depth'
>  Compiling D:/gnu/bzr/emacs/trunk/lisp/filesets.el
>  In toplevel form:
>  D:/gnu/bzr/emacs/trunk/lisp/filesets.el:1612:1:Error: Lisp nesting exceeds `max-lisp-eval-depth'
>  Compiling D:/gnu/bzr/emacs/trunk/lisp/startup.el
>  In toplevel form:
>  D:/gnu/bzr/emacs/trunk/lisp/startup.el:1295:1:Error: Lisp nesting exceeds `max-lisp-eval-depth'
>
> And later:
>
>  make[1]: *** No rule to make target `../lisp/files.elc', needed by `DOC'.  Stop.
[...]
> Does anyone else see this (on Windows or elsewhere)?

I have bootstrapped on Windows with no trouble at all (other than a
*lot* of new warnings) starting from a clean tree.

    Juanma

Re: Lexical binding

[Juanma Barranquero]

On Fri, Apr 1, 2011 at 19:32, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Just a note that the lexbind branch has been merged into trunk,

An interesting warning:

;;; file test.el  -*- lexical-binding: t -*-
(require 'cl)

(defun test (&rest args)
  (loop for x in args))
;;; end of file

=> test.el:4:1:Warning: Unused lexical variable `x'

Now, change x to _x and recompile:

=> test.el:4:1:Warning: variable `_x' not left unused


    Juanma

Re: Lexical binding

[Juanma Barranquero]

Another one:

;;; file test.el -*- lexical-binding: t -*-

(defun test (sum args)
  (dolist (arg args sum)
    (setq sum (+ sum arg))))

=> test.el:3:1:Warning: Unused lexical variable `arg'

    Juanma

Re: Lexical binding

[Stefan Monnier]

> ;;; file test.el -*- lexical-binding: t -*-

> (defun test (sum args)
>   (dolist (arg args sum)
>     (setq sum (+ sum arg))))

> => test.el:3:1:Warning: Unused lexical variable `arg'

Check the `dolist' macro, it has a FIXME for that.


        Stefan

Re: Lexical binding

[Juanma Barranquero]

On Sat, Apr 2, 2011 at 20:38, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Check the `dolist' macro, it has a FIXME for that.

OK, fair enough. Sorry for the noise.

Is this one also documented (or has a logical explanation that I'm
again missing)?

;; test.el  -*- lexical-binding: t -*-
(condition-case test
    (ignore)
  (quit test)
  (error test))
;; end

No error. Now, if you remove `test' in either handler:

 test.el:2:1:Warning: Unused lexical argument `test'

(The original test case is `isearch-search', BTW.)

    Juanma

Re: Lexical binding

[Stefan Monnier]

>> Check the `dolist' macro, it has a FIXME for that.
> OK, fair enough. Sorry for the noise.
> Is this one also documented (or has a logical explanation that I'm
> again missing)?

No, it's not documented tho it's the same underlying problem:

> ;; test.el  -*- lexical-binding: t -*-
> (condition-case test
>     (ignore)
>   (quit test)
>   (error test))
> ;; end

> No error. Now, if you remove `test' in either handler:

Right.  Internally, the condition-case above is turned into

  (condition-case :fun-body
      (lambda () (ignore))
    (quit (lambda (test) test))
    (error (lambda (test) test)))

I.e. the underlying problem (shared with dolist and some pcase
situations as well) is that one binding occurrence of a variable (above,
`test') is turned into 2 or more, so you can get warnings about an
unused variable because some of the its binders aren't used, but since
it really corresponds to a single binder in the source code the
programmer can't really fix it, hence the warning is an annoyance.

I'm not sure yet how best to solve the issue.  The main problem is
that this warning is important to help convert programs from dynamic to
lexical scoping, so it's an important tool and hence shouldn't be silenced
too lightheartedly.


        Stefan

Re: Lexical binding

[Juanma Barranquero]

On Mon, Apr 4, 2011 at 23:44, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Internally, the condition-case above is turned into
>
>  (condition-case :fun-body
>      (lambda () (ignore))
>    (quit (lambda (test) test))
>    (error (lambda (test) test)))

Aha, I understand.

> The main problem is
> that this warning is important to help convert programs from dynamic to
> lexical scoping, so it's an important tool and hence shouldn't be silenced
> too lightheartedly.

Yes, of course. I'm not complaining, just reporting problems.

    Juanma

Re: Lexical binding

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Check the `dolist' macro, it has a FIXME for that.
>> OK, fair enough. Sorry for the noise.
>> Is this one also documented (or has a logical explanation that I'm
>> again missing)?
>
> No, it's not documented tho it's the same underlying problem:
>
>> ;; test.el  -*- lexical-binding: t -*-
>> (condition-case test
>>     (ignore)
>>   (quit test)
>>   (error test))
>> ;; end
>
>> No error. Now, if you remove `test' in either handler:
>
> Right.  Internally, the condition-case above is turned into
>
>   (condition-case :fun-body
>       (lambda () (ignore))
>     (quit (lambda (test) test))
>     (error (lambda (test) test)))
>
> I.e. the underlying problem (shared with dolist and some pcase
> situations as well) is that one binding occurrence of a variable (above,
> `test') is turned into 2 or more, so you can get warnings about an
> unused variable because some of the its binders aren't used, but since
> it really corresponds to a single binder in the source code the
> programmer can't really fix it, hence the warning is an annoyance.
>
> I'm not sure yet how best to solve the issue.

Go through a stage

(condition-case :fun-body (lambda () ignore)
  (multi-lambda (x) (quit (x test) test) (error (x test) test)))

or something similar where the byte compiler does the "unused variable"
check (or a setup for it) during the multi-lambda expansion stage.  What
kind of form is exactly needed here in order to cater for all such
situations will require careful thinking.

-- 
David Kastrup

Re: Lexical binding

[Stefan Monnier]

> Go through a stage

> (condition-case :fun-body (lambda () ignore)
>   (multi-lambda (x) (quit (x test) test) (error (x test) test)))

Yes, that's my current "best plan" indeed, except it'd be

   (split-binding (test)
     (condition-case :fun-body (lambda () <foo>)
       (quit (lambda (test) test)
       (error (lambda (test) test)))

so it affects as little as possible the rest of the code.  But the above
can interfere with other uses of `test' in <foo> so it needs to be more
precise, maybe something like:
       
   (split-binding (test #:x)
     (condition-case :fun-body (lambda () <foo>)
       (quit (lambda (#:x) test)
       (error (lambda (#:x) test)))

but it's more difficult to make this work with the interpreter.

> or something similar where the byte compiler does the "unused variable"
> check (or a setup for it) during the multi-lambda expansion stage.  What
> kind of form is exactly needed here in order to cater for all such
> situations will require careful thinking.

Yes, that's currently my "best plan", but since it would also be useful
for macros like dolist/loop/pcase, it shouldn't be too hackish and work
well for the interpreted case as well.


        Stefan

Re: Lexical binding

[Stefan Monnier]

>> Just a note that the lexbind branch has been merged into trunk,

> An interesting warning:

> ;;; file test.el  -*- lexical-binding: t -*-
> (require 'cl)

> (defun test (&rest args)
>   (loop for x in args))
> ;;; end of file

> => test.el:4:1:Warning: Unused lexical variable `x'

> => test.el:4:1:Warning: variable `_x' not left unused

Indeed, if a variable is only assigned to, it's both "unused lexical
var" and "not left unused".


        Stefan

Re: Lexical binding

[Juanma Barranquero]

On Sat, Apr 2, 2011 at 20:38, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Indeed, if a variable is only assigned to, it's both "unused lexical
> var" and "not left unused".

OK, perhaps I simplified too much. The original problem is in this
function from help-fns.el:

(defun help-do-arg-highlight (doc args)
  (with-syntax-table (make-syntax-table emacs-lisp-mode-syntax-table)
    (modify-syntax-entry ?\- "w")
    (dolist (arg args doc)
      (setq doc (replace-regexp-in-string
                 ;; This is heuristic, but covers all common cases
                 ;; except ARG1-ARG2
                 (concat "\\<"                   ; beginning of word
                         "\\(?:[a-z-]*-\\)?"     ; for xxx-ARG
                         "\\("
                         (regexp-quote arg)
                         "\\)"
                         "\\(?:es\\|s\\|th\\)?"  ; for ARGth, ARGs
                         "\\(?:-[a-z0-9-]+\\)?"  ; for ARG-xxx, ARG-n
                         "\\(?:-[{([<`\"].*?\\)?"; for ARG-{x}, (x),
<x>, [x], `x'
                         "\\>")                  ; end of word
                 (help-highlight-arg arg)
                 doc t t 1)))))

=> help-fns.el:213:1:Warning: Unused lexical variable `arg'

though arg is assigned and read. Or am I missing something?

    Juanma

Re: Lexical binding

[Juanma Barranquero]

On Sat, Apr 2, 2011 at 20:50, Juanma Barranquero <lekktu@gmail.com> wrote:

> OK, perhaps I simplified too much. The original problem is in this
> function from help-fns.el:

Forget the previous message, which is about `dolist'. I mixed my examples.

The original trouble with `loop' is that, in a loop like this one,
with destructuring

 (defsubst my--bs-file-width ()
   (- (window-width)
     (loop for (name width . rest) in bs-attributes-list
         if (numberp width) sum width)
      (bs--get-name-length)
      1))

`name' is just a placeholder (as it is rest). I'm interested just in
`width'. And there's no way to write that loop as is without warnings.
Interestingly, `rest' does not produce a warning.

I suppose I can rework the loop to avoid the restructuring, but it
seems like a loss of clarity.

    Juanma

Re: Lexical binding

[Christian Ohler]

On 3/04/11 4:57, Juanma Barranquero wrote:
> The original trouble with `loop' is that, in a loop like this one,
> with destructuring
>
>   (defsubst my--bs-file-width ()
>     (- (window-width)
>       (loop for (name width . rest) in bs-attributes-list
>           if (numberp width) sum width)
>        (bs--get-name-length)
>        1))
>
> `name' is just a placeholder (as it is rest). I'm interested just in
> `width'. And there's no way to write that loop as is without warnings.

In loop destructuring, you can use nil for fields that you want to ignore:

      (loop for (nil width . nil) in bs-attributes-list
	   if (numberp width) sum width)

If you want to keep the ignored fields named, you could do something like

      (loop for (name width . rest) in bs-attributes-list
	   do (progn name rest) ; ignore
	   if (numberp width) sum width)

Christian.

Re: Lexical binding

[Juanma Barranquero]

On Sun, Apr 3, 2011 at 14:05, Christian Ohler <ohler@gnu.org> wrote:

> In loop destructuring, you can use nil for fields that you want to ignore:
>
>     (loop for (nil width . nil) in bs-attributes-list
>           if (numberp width) sum width)

Yes, but it is less informative.

> If you want to keep the ignored fields named, you could do something like
>
>     (loop for (name width . rest) in bs-attributes-list
>           do (progn name rest) ; ignore
>           if (numberp width) sum width)

And this is just ugly.

Anyway, the point is that (elisp)11.9.5.1 "Converting a package to use
lexical scoping" says:

     To silence byte-compiler warnings about unused variables, just use a
  variable name that start with an underscore, which the byte-compiler
  interpret as an indication that this is a variable known not to be used.

but this exception is quite less useful if assignments produce the
"variable `_x' not left unused" warning.

Thanks,

    Juanma

Re: Lexical binding

[Christian Ohler]

On 3/04/11 22:26, Juanma Barranquero wrote:
> On Sun, Apr 3, 2011 at 14:05, Christian Ohler<ohler@gnu.org>  wrote:
>
>> In loop destructuring, you can use nil for fields that you want to ignore:
>>
>>      (loop for (nil width . nil) in bs-attributes-list
>>            if (numberp width) sum width)
>
> Yes, but it is less informative.
>
>> If you want to keep the ignored fields named, you could do something like
>>
>>      (loop for (name width . rest) in bs-attributes-list
>>            do (progn name rest) ; ignore
>>            if (numberp width) sum width)
>
> And this is just ugly.

How about:

     (loop for (name width . rest) in bs-attributes-list
           do (ignore name rest)
           if (numberp width) sum width)


> Anyway, the point is that (elisp)11.9.5.1 "Converting a package to use
> lexical scoping" says:
>
>       To silence byte-compiler warnings about unused variables, just use a
>    variable name that start with an underscore, which the byte-compiler
>    interpret as an indication that this is a variable known not to be used.
>
> but this exception is quite less useful if assignments produce the
> "variable `_x' not left unused" warning.

IIRC, Common Lisp distinguishes between (declare (ignore ...)) and 
(declare (ignorable ...)).  The latter is useful for macros that 
introduce bindings that may or may not be used.  This doesn't really 
help with `loop', though, since it shouldn't declare its bindings ignorable.

I guess Emacs Lisp's new underscore syntax is the equivalent of (declare 
(ignore ...)), with no way to (declare (ignorable ...)).  If this is the 
case, then I agree it's not quite expressive enough, and requires idioms 
like the above (with many macros, not just `loop').

Christian.

Re: Lexical binding

[Juanma Barranquero]

On Mon, Apr 4, 2011 at 01:32, Christian Ohler <ohler@gnu.org> wrote:

> How about:
>
>    (loop for (name width . rest) in bs-attributes-list
>          do (ignore name rest)
>          if (numberp width) sum width)

All these are just workarounds, none of them pretty. I think I'll go
with using nil in the destructuring.

> IIRC, Common Lisp distinguishes between (declare (ignore ...)) and (declare
> (ignorable ...)).  The latter is useful for macros that introduce bindings
> that may or may not be used.

Yes, "3.8 The Evaluation and Compilation Dictionary", "Declaration
IGNORE, IGNORABLE" in the Common Lisp Hyperspec.

> If this is the
> case, then I agree it's not quite expressive enough, and requires idioms
> like the above (with many macros, not just `loop').

Agreed.

    Juanma

Re: Lexical binding

[Stefan Monnier]

>>> (loop for (nil width . nil) in bs-attributes-list
>>> if (numberp width) sum width)
>> Yes, but it is less informative.

BTW, I believe part of the problem is that the loop macro will use
something of the form

  (let (var)
    (while ...
      (setq var ...)
      ...))

instead of

  (while ...
    (let ((var ...))
      ...))

The former is likely to bump into the current problem, while the second
isn't.  The former is popular in Elisp because it's slightly faster, but
with lexical scoping the second is actually more efficient.  This is in
part because a lexical `let' is cheaper so it can be moved into the loop
without problems, and in other part because the second form avoids some
more costly cases:

let's take `dotimes' as an example.  What should

  (let ((res ()))
    (dotimes (i 3) (push (lambda () i) res))
    res)

return?  Clearly it will be a list of 3 functions, each one taking
0 args and returning a number, but what should the exact return value
be?  With the let-while-setq form of the loop, you'd get three times the
same function returning 3, whereas with the while-let form you'd get
functions returning 2, 1, and 0.

To get the first result, you need to make sure all three functions refer
to some memory cell holding the value of the variable `i', so you get an
extra indirection.  I also find the second behavior more desirable.
So I've changed the dotimes (and dolist) macros to use the while-let
instead of let-while-setq form when used with lexical scoping.

Maybe we should do the same for loop, but I'm definitely not going to
take on this challenge.


        Stefan