bug#66756: 30.0.50; [PATCH] Improve discussion of 'let' in Elisp Introduction manual

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 24 Nov 2023 01:01:33 -0800
> Cc: rms@gnu.org, 66756@debbugs.gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> >> +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").

"During the execution" is probably a good idea, but "within the body
of the expression" Does not seem to contrast with that, since it also
holds for dynamic binding.

I think the explanation should focus on the code of getx, not on the
code in the 'let'-form's body.  The reason for what happens under
lexical binding is in getx.