From: Jim Porter <jporterbugs@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: rms@gnu.org, 66756@debbugs.gnu.org
Subject: bug#66756: 30.0.50; [PATCH] Improve discussion of 'let' in Elisp Introduction manual
Date: Fri, 24 Nov 2023 01:01:33 -0800 [thread overview]
Message-ID: <64d90b0b-e003-7bc3-5312-6c7ab4c4591f@gmail.com> (raw)
In-Reply-To: <83jzq7fx5o.fsf@gnu.org>
Thanks for taking a look, Eli. Just a few questions/thoughts on some of
your comments. (I trimmed the others since I'll probably rework the
other sections based on how we handle the second part below.)
On 11/23/2023 11:06 PM, Eli Zaretskii wrote:
> FWIW, I find the use of "overshadows" in the original text to be
> better than the "overrides" in the new text. This is partly because
> the meaning of "override" is not clear when talking about the use of a
> name, and partly because "override" is really inaccurate here. If we
> are not happy with the original text, then we need to find something
> else, IMO, perhaps a more detailed description.
Maybe we should just leave it as is for now? I don't think it's strictly
necessary to change that sentence for the rest of the patch to make
sense. We could always improve it in a follow up.
(Or if someone has the perfect phrase to use here, I'll happily make the
change. I just don't want the patch to get bogged down by changes that
are merely *near* the parts I'm working on.)
>> +As we discussed before, under lexical binding, @code{let} defines a
>> +@emph{place} in your code where the variables have their own local
>> +meaning. Under dynamic binding, the rules are different: instead, you
>> +are defining a @emph{time} in your code when the variables have their
>> +own local meaning.
>
> If this wants to explain the difference between compile-time and
> run-time binding, then perhaps it should say so, instead of talking
> about the confusing "place where" vs "time when" the value changes?
> And if compile-time is problematic (Emacs being an interpreter), then
> we should find another description, one that doesn't use confusing
> concept of "place".
I'm open to other wordings, but I wanted to describe what's going on
without getting into the details of the interpreter or how it evaluates
the code. The "place" is supposed to refer to the actual body of the
'let' form. That's described in the first part I changed. However, the
"time" description could probably be expanded.
Maybe we could contrast "within the body of the let expression" vs
"during execution of the let expression"? That gets across the idea to
me that the former is about compile-time ("body" refers to the actual
Lisp form), while the latter is about run-time ("execution").
next prev parent reply other threads:[~2023-11-24 9:01 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-26 5:54 bug#66756: 30.0.50; [PATCH] Improve discussion of 'let' in Elisp Introduction manual Jim Porter
2023-10-26 18:30 ` Jim Porter
2023-10-29 16:38 ` Richard Stallman
2023-10-29 17:18 ` Drew Adams
2023-11-18 2:09 ` Jim Porter
2023-11-19 3:39 ` Richard Stallman
2023-11-19 5:25 ` Jim Porter
2023-11-19 5:30 ` Jim Porter
2023-11-19 8:38 ` Michael Albinus
2023-11-19 20:17 ` Jim Porter
2023-11-19 23:05 ` Jim Porter
2023-11-20 13:28 ` Michael Albinus
2023-11-23 2:57 ` Richard Stallman
2023-11-23 21:04 ` Jim Porter
2023-11-24 7:06 ` Eli Zaretskii
2023-11-24 9:01 ` Jim Porter [this message]
2023-11-24 11:41 ` Eli Zaretskii
2023-11-24 21:46 ` Jim Porter
2023-11-25 7:51 ` Eli Zaretskii
2023-11-30 21:03 ` Jim Porter
2023-12-01 8:29 ` Eli Zaretskii
2023-12-04 3:08 ` Richard Stallman
2023-12-04 3:08 ` Richard Stallman
2023-12-04 4:34 ` Jim Porter
2023-12-10 19:36 ` Jim Porter
2023-12-16 23:10 ` Stefan Kangas
2023-12-17 20:47 ` Jim Porter
2024-01-09 18:40 ` Jim Porter
2023-12-04 3:08 ` Richard Stallman
2023-11-04 8:27 ` Eli Zaretskii
2023-11-04 16:44 ` Jim Porter
2023-11-06 2:29 ` Richard Stallman
2023-11-06 2:29 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64d90b0b-e003-7bc3-5312-6c7ab4c4591f@gmail.com \
--to=jporterbugs@gmail.com \
--cc=66756@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).