From: "Bruno Félix Rezende Ribeiro" <oitofelix@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: defvar without value
Date: Fri, 10 Apr 2020 12:20:46 -0300 [thread overview]
Message-ID: <877dyngyep.fsf@oitofelix.com> (raw)
In-Reply-To: 87blo0mdwi.fsf@ebih.ebihd
[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]
Hi Emanuel,
Emanuel Berg via "Emacs development discussions." <emacs-devel@gnu.org>
writes:
> The supposedly parallel version isn't needed in my experience if there
> is `let*' [...] Maybe `let' will truly be parallel one day [...]
That’s not the only use of ‘let’, because it’s not a weaker form of
‘let*’ as one might first think. Both are fundamentally different in
their operation and ‘let’ is indeed parallel in some strict theoretical
sense, in the same way ‘let*’ is sequential in the same sense. Both
forms coincide in effect only in the trivial case: when there is no
reference to (textually) earlier variables being bound in the subsequent
forms being evaluated to obtain the values to be bound to the later
ones.
For instance consider the difference between
#+BEGIN_SRC elisp
(let ((x 0))
(let ((x (1- x))
(y (1+ x)))
(cons x y)))
#+END_SRC
and
#+BEGIN_SRC elisp
(let ((x 0))
(let* ((x (1- x))
(y (1+ x)))
(cons x y)))
#+END_SRC
The former evaluates to ~(-1 . 1)~ while the latter to ~(-1 . 0)~. Both
are valid expressions with sensible behavior and are not
interchangeable. The answer to which one to use does *not* follow from
the criterion: “are the variables to be bound interdependent?”, since in
both cases they are (and the behavior is different). The real question
to answer is: “should they be bound in sequence or in parallel?”
--
Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
<http://oitofelix.freeshell.org/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
next prev parent reply other threads:[~2020-04-10 15:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-01 0:03 defvar without value Michael Heerdegen
2020-04-01 0:36 ` Drew Adams
2020-04-01 0:59 ` Stefan Monnier
2020-04-01 22:45 ` Michael Heerdegen
2020-04-02 2:37 ` Stefan Monnier
2020-04-09 1:52 ` Michael Heerdegen
2020-04-09 2:04 ` Emanuel Berg via Emacs development discussions.
2020-04-09 2:20 ` Stefan Monnier
2020-04-09 23:34 ` Emanuel Berg via Emacs development discussions.
2020-04-10 15:20 ` Bruno Félix Rezende Ribeiro [this message]
2020-04-10 23:07 ` Emanuel Berg via Emacs development discussions.
2020-04-10 21:57 ` Michael Heerdegen
2020-04-01 1:21 ` Noam Postavsky
2020-04-01 1:53 ` Michael Heerdegen
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=877dyngyep.fsf@oitofelix.com \
--to=oitofelix@gnu.org \
--cc=emacs-devel@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).