all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 67116@debbugs.gnu.org, acm@muc.de
Subject: bug#67116: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference.
Date: Sun, 12 Nov 2023 11:49:55 -0500	[thread overview]
Message-ID: <jwvjzqmvs7g.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83r0kvv6r0.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 12 Nov 2023 08:13:39 +0200")

>> Sounds like a bug.
> It does?  I always thought that the order of evaluation in a let form
> is unspecified,

I'm not sure if we say so explicitly somewhere, but ELisp's order of
evaluation is very much always "left to right" and that carries over to
`let`.

> Why on Earth should we require any particular order of evaluation in
> a let form??

That's a popular bikeshedding subject, actually.

On one side you have the proponents of leaving the order unspecified
(like in C and Scheme) on the premise that it allows more choice for the
compiler, on the other you have the proponents of specifying the order
so as to remove an ugly corner case that bites programmers.

I am personally not swayed by the optimization argument (tho the OCaml
bytecode compiler had a good argument in favor of right-to-left
evaluation order) and in the case of ELisp, there's a lot of code out
there which already relies on the current evaluation order.


        Stefan






  parent reply	other threads:[~2023-11-12 16:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-11 22:48 bug#67116: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference Alan Mackenzie
2023-11-12  4:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-12  6:13   ` Eli Zaretskii
2023-11-12 14:22     ` Alan Mackenzie
2023-11-12 19:32       ` Drew Adams
2023-11-14  2:56         ` Richard Stallman
2023-11-12 16:49     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-11-12 14:54   ` Alan Mackenzie
2023-11-12 17:06     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-12 14:21 ` Mattias Engdegård
2023-11-12 14:41   ` Mattias Engdegård
2023-11-13 11:19     ` Mattias Engdegård
2023-11-13 13:14       ` Alan Mackenzie

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvjzqmvs7g.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=67116@debbugs.gnu.org \
    --cc=acm@muc.de \
    --cc=eliz@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.