* Lexical binding
@ 2011-04-01 17:32 Stefan Monnier
2011-04-01 19:12 ` David De La Harpe Golden
` (5 more replies)
0 siblings, 6 replies; 30+ messages in thread
From: Stefan Monnier @ 2011-04-01 17:32 UTC (permalink / raw
To: emacs-devel
Just a note that the lexbind branch has been merged into trunk,
Stefan
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-01 17:32 Lexical binding Stefan Monnier
@ 2011-04-01 19:12 ` David De La Harpe Golden
2011-04-01 19:46 ` Eli Zaretskii
` (4 subsequent siblings)
5 siblings, 0 replies; 30+ messages in thread
From: David De La Harpe Golden @ 2011-04-01 19:12 UTC (permalink / raw
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-01 17:32 Lexical binding Stefan Monnier
2011-04-01 19:12 ` David De La Harpe Golden
@ 2011-04-01 19:46 ` Eli Zaretskii
2011-04-04 16:05 ` Stefan Monnier
2011-04-01 20:04 ` Daniel Colascione
` (3 subsequent siblings)
5 siblings, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2011-04-01 19:46 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-01 17:32 Lexical binding Stefan Monnier
2011-04-01 19:12 ` David De La Harpe Golden
2011-04-01 19:46 ` Eli Zaretskii
@ 2011-04-01 20:04 ` Daniel Colascione
2011-04-01 20:39 ` cedet-bzr build failure (was : Lexical binding) Darren Hoo
` (2 subsequent siblings)
5 siblings, 0 replies; 30+ messages in thread
From: Daniel Colascione @ 2011-04-01 20:04 UTC (permalink / raw
To: emacs-devel
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. :)
^ permalink raw reply [flat|nested] 30+ messages in thread
* cedet-bzr build failure (was : Lexical binding)
2011-04-01 17:32 Lexical binding Stefan Monnier
` (2 preceding siblings ...)
2011-04-01 20:04 ` Daniel Colascione
@ 2011-04-01 20:39 ` Darren Hoo
2011-04-01 21:21 ` David Engster
2011-04-01 20:42 ` Lexical binding Eli Zaretskii
2011-04-02 2:33 ` Juanma Barranquero
5 siblings, 1 reply; 30+ messages in thread
From: Darren Hoo @ 2011-04-01 20:39 UTC (permalink / raw
To: emacs-devel
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")
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-01 17:32 Lexical binding Stefan Monnier
` (3 preceding siblings ...)
2011-04-01 20:39 ` cedet-bzr build failure (was : Lexical binding) Darren Hoo
@ 2011-04-01 20:42 ` Eli Zaretskii
2011-04-01 22:13 ` Juanma Barranquero
2011-04-02 2:33 ` Juanma Barranquero
5 siblings, 1 reply; 30+ messages in thread
From: Eli Zaretskii @ 2011-04-01 20:42 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
> 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)?
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cedet-bzr build failure (was : Lexical binding)
2011-04-01 20:39 ` cedet-bzr build failure (was : Lexical binding) Darren Hoo
@ 2011-04-01 21:21 ` David Engster
2011-04-01 22:26 ` Darren Hoo
0 siblings, 1 reply; 30+ messages in thread
From: David Engster @ 2011-04-01 21:21 UTC (permalink / raw
To: Darren Hoo; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-01 20:42 ` Lexical binding Eli Zaretskii
@ 2011-04-01 22:13 ` Juanma Barranquero
0 siblings, 0 replies; 30+ messages in thread
From: Juanma Barranquero @ 2011-04-01 22:13 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cedet-bzr build failure (was : Lexical binding)
2011-04-01 21:21 ` David Engster
@ 2011-04-01 22:26 ` Darren Hoo
2011-04-02 12:40 ` David Engster
0 siblings, 1 reply; 30+ messages in thread
From: Darren Hoo @ 2011-04-01 22:26 UTC (permalink / raw
To: emacs-devel
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*"
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-01 17:32 Lexical binding Stefan Monnier
` (4 preceding siblings ...)
2011-04-01 20:42 ` Lexical binding Eli Zaretskii
@ 2011-04-02 2:33 ` Juanma Barranquero
2011-04-02 3:36 ` Juanma Barranquero
2011-04-02 18:38 ` Stefan Monnier
5 siblings, 2 replies; 30+ messages in thread
From: Juanma Barranquero @ 2011-04-02 2:33 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-02 2:33 ` Juanma Barranquero
@ 2011-04-02 3:36 ` Juanma Barranquero
2011-04-02 18:38 ` Stefan Monnier
2011-04-02 18:38 ` Stefan Monnier
1 sibling, 1 reply; 30+ messages in thread
From: Juanma Barranquero @ 2011-04-02 3:36 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cedet-bzr build failure (was : Lexical binding)
2011-04-01 22:26 ` Darren Hoo
@ 2011-04-02 12:40 ` David Engster
2011-04-02 13:42 ` Eric M. Ludlam
2011-04-02 18:29 ` cedet-bzr build failure (was : Lexical binding) Darren Hoo
0 siblings, 2 replies; 30+ messages in thread
From: David Engster @ 2011-04-02 12:40 UTC (permalink / raw
To: Darren Hoo; +Cc: Eric M. Ludlam, emacs-devel
[-- 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)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cedet-bzr build failure (was : Lexical binding)
2011-04-02 12:40 ` David Engster
@ 2011-04-02 13:42 ` Eric M. Ludlam
2011-04-02 18:22 ` cedet-bzr build failure David Engster
2011-04-02 18:29 ` cedet-bzr build failure (was : Lexical binding) Darren Hoo
1 sibling, 1 reply; 30+ messages in thread
From: Eric M. Ludlam @ 2011-04-02 13:42 UTC (permalink / raw
To: Darren Hoo, emacs-devel
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
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cedet-bzr build failure
2011-04-02 13:42 ` Eric M. Ludlam
@ 2011-04-02 18:22 ` David Engster
0 siblings, 0 replies; 30+ messages in thread
From: David Engster @ 2011-04-02 18:22 UTC (permalink / raw
To: Eric M. Ludlam; +Cc: emacs-devel, Darren Hoo
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cedet-bzr build failure (was : Lexical binding)
2011-04-02 12:40 ` David Engster
2011-04-02 13:42 ` Eric M. Ludlam
@ 2011-04-02 18:29 ` Darren Hoo
1 sibling, 0 replies; 30+ messages in thread
From: Darren Hoo @ 2011-04-02 18:29 UTC (permalink / raw
To: Darren Hoo, emacs-devel, Eric M. Ludlam; +Cc: David Engster
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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-02 2:33 ` Juanma Barranquero
2011-04-02 3:36 ` Juanma Barranquero
@ 2011-04-02 18:38 ` Stefan Monnier
2011-04-02 18:50 ` Juanma Barranquero
1 sibling, 1 reply; 30+ messages in thread
From: Stefan Monnier @ 2011-04-02 18:38 UTC (permalink / raw
To: Juanma Barranquero; +Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-02 3:36 ` Juanma Barranquero
@ 2011-04-02 18:38 ` Stefan Monnier
2011-04-04 16:04 ` Juanma Barranquero
0 siblings, 1 reply; 30+ messages in thread
From: Stefan Monnier @ 2011-04-02 18:38 UTC (permalink / raw
To: Juanma Barranquero; +Cc: emacs-devel
> ;;; 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-02 18:38 ` Stefan Monnier
@ 2011-04-02 18:50 ` Juanma Barranquero
2011-04-02 18:57 ` Juanma Barranquero
0 siblings, 1 reply; 30+ messages in thread
From: Juanma Barranquero @ 2011-04-02 18:50 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-02 18:50 ` Juanma Barranquero
@ 2011-04-02 18:57 ` Juanma Barranquero
2011-04-03 12:05 ` Christian Ohler
0 siblings, 1 reply; 30+ messages in thread
From: Juanma Barranquero @ 2011-04-02 18:57 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-02 18:57 ` Juanma Barranquero
@ 2011-04-03 12:05 ` Christian Ohler
2011-04-03 12:26 ` Juanma Barranquero
0 siblings, 1 reply; 30+ messages in thread
From: Christian Ohler @ 2011-04-03 12:05 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-03 12:05 ` Christian Ohler
@ 2011-04-03 12:26 ` Juanma Barranquero
2011-04-03 23:32 ` Christian Ohler
0 siblings, 1 reply; 30+ messages in thread
From: Juanma Barranquero @ 2011-04-03 12:26 UTC (permalink / raw
To: Christian Ohler; +Cc: Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-03 12:26 ` Juanma Barranquero
@ 2011-04-03 23:32 ` Christian Ohler
2011-04-04 0:12 ` Juanma Barranquero
2011-04-04 16:22 ` Stefan Monnier
0 siblings, 2 replies; 30+ messages in thread
From: Christian Ohler @ 2011-04-03 23:32 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-03 23:32 ` Christian Ohler
@ 2011-04-04 0:12 ` Juanma Barranquero
2011-04-04 16:22 ` Stefan Monnier
1 sibling, 0 replies; 30+ messages in thread
From: Juanma Barranquero @ 2011-04-04 0:12 UTC (permalink / raw
To: Christian Ohler; +Cc: Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-02 18:38 ` Stefan Monnier
@ 2011-04-04 16:04 ` Juanma Barranquero
2011-04-04 21:44 ` Stefan Monnier
0 siblings, 1 reply; 30+ messages in thread
From: Juanma Barranquero @ 2011-04-04 16:04 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-01 19:46 ` Eli Zaretskii
@ 2011-04-04 16:05 ` Stefan Monnier
0 siblings, 0 replies; 30+ messages in thread
From: Stefan Monnier @ 2011-04-04 16:05 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-03 23:32 ` Christian Ohler
2011-04-04 0:12 ` Juanma Barranquero
@ 2011-04-04 16:22 ` Stefan Monnier
1 sibling, 0 replies; 30+ messages in thread
From: Stefan Monnier @ 2011-04-04 16:22 UTC (permalink / raw
To: Christian Ohler; +Cc: Juanma Barranquero, emacs-devel
>>> (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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-04 16:04 ` Juanma Barranquero
@ 2011-04-04 21:44 ` Stefan Monnier
2011-04-04 21:56 ` Juanma Barranquero
2011-04-04 22:03 ` David Kastrup
0 siblings, 2 replies; 30+ messages in thread
From: Stefan Monnier @ 2011-04-04 21:44 UTC (permalink / raw
To: Juanma Barranquero; +Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-04 21:44 ` Stefan Monnier
@ 2011-04-04 21:56 ` Juanma Barranquero
2011-04-04 22:03 ` David Kastrup
1 sibling, 0 replies; 30+ messages in thread
From: Juanma Barranquero @ 2011-04-04 21:56 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-04 21:44 ` Stefan Monnier
2011-04-04 21:56 ` Juanma Barranquero
@ 2011-04-04 22:03 ` David Kastrup
2011-04-04 22:34 ` Stefan Monnier
1 sibling, 1 reply; 30+ messages in thread
From: David Kastrup @ 2011-04-04 22:03 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Lexical binding
2011-04-04 22:03 ` David Kastrup
@ 2011-04-04 22:34 ` Stefan Monnier
0 siblings, 0 replies; 30+ messages in thread
From: Stefan Monnier @ 2011-04-04 22:34 UTC (permalink / raw
To: David Kastrup; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2011-04-04 22:34 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-01 17:32 Lexical binding Stefan Monnier
2011-04-01 19:12 ` David De La Harpe Golden
2011-04-01 19:46 ` Eli Zaretskii
2011-04-04 16:05 ` Stefan Monnier
2011-04-01 20:04 ` Daniel Colascione
2011-04-01 20:39 ` cedet-bzr build failure (was : Lexical binding) Darren Hoo
2011-04-01 21:21 ` David Engster
2011-04-01 22:26 ` Darren Hoo
2011-04-02 12:40 ` David Engster
2011-04-02 13:42 ` Eric M. Ludlam
2011-04-02 18:22 ` cedet-bzr build failure David Engster
2011-04-02 18:29 ` cedet-bzr build failure (was : Lexical binding) Darren Hoo
2011-04-01 20:42 ` Lexical binding Eli Zaretskii
2011-04-01 22:13 ` Juanma Barranquero
2011-04-02 2:33 ` Juanma Barranquero
2011-04-02 3:36 ` Juanma Barranquero
2011-04-02 18:38 ` Stefan Monnier
2011-04-04 16:04 ` Juanma Barranquero
2011-04-04 21:44 ` Stefan Monnier
2011-04-04 21:56 ` Juanma Barranquero
2011-04-04 22:03 ` David Kastrup
2011-04-04 22:34 ` Stefan Monnier
2011-04-02 18:38 ` Stefan Monnier
2011-04-02 18:50 ` Juanma Barranquero
2011-04-02 18:57 ` Juanma Barranquero
2011-04-03 12:05 ` Christian Ohler
2011-04-03 12:26 ` Juanma Barranquero
2011-04-03 23:32 ` Christian Ohler
2011-04-04 0:12 ` Juanma Barranquero
2011-04-04 16:22 ` Stefan Monnier
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.