GNU bug report logs -
#62840
30.0.50; Doc bug: obsolete paragraph in Elisp Ref
Previous Next
Reported by: Nick Dokos <ndokos <at> gmail.com>
Date: Fri, 14 Apr 2023 17:50:01 UTC
Severity: normal
Found in version 30.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 62840 in the body.
You can then email your comments to 62840 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#62840
; Package
emacs
.
(Fri, 14 Apr 2023 17:50:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Nick Dokos <ndokos <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 14 Apr 2023 17:50:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
---------------------------------------------------------------------------
Emacs Lisp Reference manual, Chapter "Variables", Section "Lexical
Binding" says:
--8<---------------cut here---------------start------------->8---
...
(Internally, the lexical environment is an alist of symbol-value
pairs, with the final element in the alist being the symbol ‘t’ rather
than a cons cell. Such an alist can be passed as the second argument to
the ‘eval’ function, in order to specify a lexical environment in which
to evaluate a form. *Note Eval::. Most Emacs Lisp programs, however,
should not interact directly with lexical environments in this way; only
specialized programs like debuggers.)
...
--8<---------------cut here---------------end--------------->8---
I don't know if the structure of the lexical environment was ever really
relevant: it seems to be an internal detail that should not have found
its way into the documentation in the first place, but that's guessing
on my part.
The important thing is that it does not seem to be the case any longer:
the `t' is present at the end of the lexical environment in Emacs 28.2:
(let ((foo 233)) (lambda (x) (* x foo))) ==> (closure ((foo . 233) t) (x) (* x foo))
but it is no longer present in current upstream:
(let ((foo 233)) (lambda (x) (* x foo))) ==> (closure ((foo . 233)) (x) (* x foo))
so the above paragraph needs modification (if not outright excision).
--
Nick
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#62840
; Package
emacs
.
(Sat, 15 Apr 2023 08:40:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 62840 <at> debbugs.gnu.org (full text, mbox):
> From: Nick Dokos <ndokos <at> gmail.com>
> Date: Fri, 14 Apr 2023 13:48:59 -0400
>
>
> ---------------------------------------------------------------------------
> Emacs Lisp Reference manual, Chapter "Variables", Section "Lexical
> Binding" says:
>
> --8<---------------cut here---------------start------------->8---
> ...
> (Internally, the lexical environment is an alist of symbol-value
> pairs, with the final element in the alist being the symbol ‘t’ rather
> than a cons cell. Such an alist can be passed as the second argument to
> the ‘eval’ function, in order to specify a lexical environment in which
> to evaluate a form. *Note Eval::. Most Emacs Lisp programs, however,
> should not interact directly with lexical environments in this way; only
> specialized programs like debuggers.)
>
> ...
> --8<---------------cut here---------------end--------------->8---
>
> I don't know if the structure of the lexical environment was ever really
> relevant: it seems to be an internal detail that should not have found
> its way into the documentation in the first place, but that's guessing
> on my part.
>
> The important thing is that it does not seem to be the case any longer:
> the `t' is present at the end of the lexical environment in Emacs 28.2:
>
> (let ((foo 233)) (lambda (x) (* x foo))) ==> (closure ((foo . 233) t) (x) (* x foo))
>
> but it is no longer present in current upstream:
>
> (let ((foo 233)) (lambda (x) (* x foo))) ==> (closure ((foo . 233)) (x) (* x foo))
>
> so the above paragraph needs modification (if not outright excision).
Stefan, any comments? Should this text be amended, deleted, or
something else?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#62840
; Package
emacs
.
(Sat, 15 Apr 2023 13:12:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 62840 <at> debbugs.gnu.org (full text, mbox):
>> I don't know if the structure of the lexical environment was ever really
>> relevant: it seems to be an internal detail that should not have found
>> its way into the documentation in the first place, but that's guessing
>> on my part.
>>
>> The important thing is that it does not seem to be the case any longer:
>> the `t' is present at the end of the lexical environment in Emacs 28.2:
>>
>> (let ((foo 233)) (lambda (x) (* x foo))) ==> (closure ((foo . 233) t) (x) (* x foo))
>>
>> but it is no longer present in current upstream:
>>
>> (let ((foo 233)) (lambda (x) (* x foo))) ==> (closure ((foo . 233)) (x) (* x foo))
>>
>> so the above paragraph needs modification (if not outright excision).
>
> Stefan, any comments? Should this text be amended, deleted, or
> something else?
Indeed the "with a `t` at the end" should probably not have been
documented and can be removed. The `t` can still appear there
(sometimes it does sometimes it doesn't). More important would be to
document that beside (SYM . VAL) pairs, the env can contain symbols,
which means that the lexical environment declared that variable as being
locally considered as a dynbind variable.
E.g. in
(defun my-fun (baz)
(defvar my-foo)
(lambda (x) (let ((my-foo x)) (bar baz))))
`my-foo` will appear in the environment of the closure returned by the
function so as to remember the `defvar` since it affects the execution
of the body.
Stefan
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Tue, 18 Apr 2023 11:32:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Nick Dokos <ndokos <at> gmail.com>
:
bug acknowledged by developer.
(Tue, 18 Apr 2023 11:32:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 62840-done <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Nick Dokos <ndokos <at> gmail.com>, 62840 <at> debbugs.gnu.org
> Date: Sat, 15 Apr 2023 09:11:37 -0400
>
> Indeed the "with a `t` at the end" should probably not have been
> documented and can be removed. The `t` can still appear there
> (sometimes it does sometimes it doesn't). More important would be to
> document that beside (SYM . VAL) pairs, the env can contain symbols,
> which means that the lexical environment declared that variable as being
> locally considered as a dynbind variable.
>
> E.g. in
>
> (defun my-fun (baz)
> (defvar my-foo)
> (lambda (x) (let ((my-foo x)) (bar baz))))
>
> `my-foo` will appear in the environment of the closure returned by the
> function so as to remember the `defvar` since it affects the execution
> of the body.
Thanks, fixed on the emacs-29 branch, and closing the bug.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 17 May 2023 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 91 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.