From: Drew Adams <drew.adams@oracle.com>
To: Cecil Westerhof <Cecil@decebal.nl>, help-gnu-emacs@gnu.org
Subject: RE: Always using let*
Date: Mon, 15 Sep 2014 09:15:14 -0700 (PDT) [thread overview]
Message-ID: <9dddedeb-1b55-4d6e-9fd1-5cd23b9b47b0@default> (raw)
In-Reply-To: <93faab1c-96bd-4188-9686-3869fc027601@default>
> > Would it be OK to always use let*? I was just bitten by the fact
> > that with let you can not previous variables from the let
> > statement, as is possible with setq. So I am thinking about always
> > using let*, so I do not have to think about it. Or are there good
> > reasons to use let when you do not need let*?
>
> The most common reason is when you want to use a variable value
> in the cadr of a binding and you do *not* want to pick up the
> variable's newly bound value. IOW, precisely the opposite use
> case of what you wanted when you were bit.
>
> (setq c 3)
> (let ((c (+ c 4)) (b (* c 42))) ; Use original C value: 3 ...)
I should point out another reason why some people, including me,
might use one or the other: To help humans read the code.
When I use `let' I communicate that none of the bindings depend
on earlier bindings. (The bindings are independent, which does
not imply that their values are.) In particular, when a variable
appears in the right side of a binding expression it is not a
variable that is bound by that `let' (it may be the same symbol,
but it is a different variable).
In sum: If I use `let*' then look for a binding dependency.
If I use `let' then don't bother to look for one.
If the actual behavior of the code does not correspond to that
message then the code is bugged. The point of such a convention
is that a reader can more easily and quickly understand the code
wrt my intention.
And yes, this does mean that I end up editing the code, changing
some `let's to `let*'s later, and vice versa, as it evolves.
I am *not* trying to minimize my effort when writing code ("so I
do not have to think about it" is misguided, IMHO). I am instead
trying to minimize (human) reader effort - my code is not just
about me. And yet I benefit from this more than anyone else, as
I am the main reader. (And if others can more easily read it
then I benefit from their better bug reports.)
It's easy to write code. It's harder to understand code you have
not written (just now) and to modify it without screwing things up.
Yes, it's a minor consideration, but it is one that affects how
I code, at least. YMMV.
next prev parent reply other threads:[~2014-09-15 16:15 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-14 19:46 Always using let* Cecil Westerhof
2014-09-14 21:25 ` Drew Adams
2014-09-15 16:15 ` Drew Adams [this message]
[not found] ` <mailman.8924.1410797740.1147.help-gnu-emacs@gnu.org>
2014-09-15 18:01 ` Cecil Westerhof
2014-09-15 22:20 ` Emanuel Berg
2014-09-16 12:05 ` Cecil Westerhof
2014-09-16 22:40 ` Emanuel Berg
2014-09-18 17:02 ` Cecil Westerhof
2014-09-18 21:05 ` Emanuel Berg
2014-09-16 14:23 ` sokobania.01
2014-09-16 16:41 ` Drew Adams
2014-09-16 20:49 ` Stefan Monnier
2014-09-16 22:45 ` Emanuel Berg
[not found] ` <mailman.8998.1410901776.1147.help-gnu-emacs@gnu.org>
2014-09-16 22:48 ` Emanuel Berg
2014-09-17 1:09 ` Stefan Monnier
2014-09-17 1:18 ` Emanuel Berg
2014-09-14 21:40 ` Joe Fineman
[not found] ` <mailman.8868.1410729956.1147.help-gnu-emacs@gnu.org>
2014-09-14 21:41 ` Emanuel Berg
2014-09-14 22:11 ` Cecil Westerhof
2014-09-14 22:56 ` Drew Adams
2014-09-14 22:41 ` Stefan Monnier
2014-09-14 23:06 ` Drew Adams
[not found] ` <mailman.8871.1410736002.1147.help-gnu-emacs@gnu.org>
2014-09-15 0:47 ` Emanuel Berg
2014-09-15 2:12 ` Pascal J. Bourguignon
2014-09-15 2:22 ` Stefan Monnier
2014-09-15 2:59 ` Pascal J. Bourguignon
2014-09-15 12:31 ` Stefan Monnier
2014-09-15 16:15 ` Drew Adams
2014-09-15 19:05 ` Stefan Monnier
[not found] ` <mailman.8930.1410808006.1147.help-gnu-emacs@gnu.org>
2014-09-15 22:28 ` Emanuel Berg
2014-09-16 0:38 ` Pascal J. Bourguignon
2014-09-15 13:14 ` Barry Margolin
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=9dddedeb-1b55-4d6e-9fd1-5cd23b9b47b0@default \
--to=drew.adams@oracle.com \
--cc=Cecil@decebal.nl \
--cc=help-gnu-emacs@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.
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).