From unknown Fri Aug 15 16:00:23 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#67116 <67116@debbugs.gnu.org> To: bug#67116 <67116@debbugs.gnu.org> Subject: Status: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference. Reply-To: bug#67116 <67116@debbugs.gnu.org> Date: Fri, 15 Aug 2025 23:00:23 +0000 retitle 67116 byte-compile-let: reversing the order of evaluation of the cl= auses CAN make a difference. reassign 67116 emacs submitter 67116 Alan Mackenzie severity 67116 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 11 17:49:38 2023 Received: (at submit) by debbugs.gnu.org; 11 Nov 2023 22:49:38 +0000 Received: from localhost ([127.0.0.1]:54650 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r1wnK-0001xL-I4 for submit@debbugs.gnu.org; Sat, 11 Nov 2023 17:49:38 -0500 Received: from lists.gnu.org ([2001:470:142::17]:49288) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r1wnI-0001x8-Ej for submit@debbugs.gnu.org; Sat, 11 Nov 2023 17:49:36 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1wmY-0007Gc-Ai for bug-gnu-emacs@gnu.org; Sat, 11 Nov 2023 17:48:50 -0500 Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1wmV-0005cb-QO for bug-gnu-emacs@gnu.org; Sat, 11 Nov 2023 17:48:50 -0500 Received: (qmail 80496 invoked by uid 3782); 11 Nov 2023 23:48:44 +0100 Received: from acm.muc.de (p4fe151aa.dip0.t-ipconnect.de [79.225.81.170]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 11 Nov 2023 23:48:43 +0100 Received: (qmail 10921 invoked by uid 1000); 11 Nov 2023 22:48:43 -0000 Date: Sat, 11 Nov 2023 22:48:43 +0000 To: bug-gnu-emacs@gnu.org Subject: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit Cc: Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Hello, Emacs. Emacs master branch. In lisp/emacs-lisp/bytecomp.el (byte-compile-let), when the following form (from jit-lock--debug-fontify): (let ((beg pos) (end (setq pos (next-single-property-change pos 'fontified nil (point-max))))) (put-text-property beg end 'fontified nil) (jit-lock-fontify-now beg end)) gets byte compiled, the order of evaluating BEG and END gets reversed so that END gets evaluated first. Since the value for END contains (setq pos ...), BEG gets this updated value of POS rather then the original intended value. This particular bug in jit-lock.el can be fixed by using let* rather than let, but this isn't the point. I believe (without testing) that the interpreted code for the form would evaluate BEG before END, hence testing it interpreted (e.g. under edebug) will give a false sense of correctness. The comment in byte-compile-let: ;; Bind the variables. ;; For `let', do it in reverse order, because it makes no ;; semantic difference, but it is a lot more efficient since the ;; values are now in reverse order on the stack. , is not true. It can make a semantic difference. So doing the binding in reverse order is a bug. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 11 23:53:36 2023 Received: (at submit) by debbugs.gnu.org; 12 Nov 2023 04:53:36 +0000 Received: from localhost ([127.0.0.1]:54945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r22TX-00036I-S3 for submit@debbugs.gnu.org; Sat, 11 Nov 2023 23:53:36 -0500 Received: from lists.gnu.org ([2001:470:142::17]:59722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r22TT-000361-LY for submit@debbugs.gnu.org; Sat, 11 Nov 2023 23:53:33 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r22Sj-0006zP-35 for bug-gnu-emacs@gnu.org; Sat, 11 Nov 2023 23:52:45 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r22Sh-0000Uh-9b for bug-gnu-emacs@gnu.org; Sat, 11 Nov 2023 23:52:44 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3C393441802; Sat, 11 Nov 2023 23:52:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1699764760; bh=YSCvPb5koVfWujPVwQb6PpbISfnNhCCNTAa/T8Uv7bo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JGXAIaYlDTVBO1ayWWurjmB7Ie9ovlvBsvEgwxqNIpMK9SF0h3cGAsNcLAPwsy/P1 cRb8HsIIWZFiMpeSRs4qcGHBhZgLeDripcat31VAAOmkPTpA0IFkq5VOsCfF0y4VJq sP8Xo74Ktrstrc/LYDEhuHeKAUV3pZvcNMbmRjQHWBiEYSw/5u08oVzvMcnU/8nklq 5/f0CibDuGdE6zu8hjm3OYKudsVD86QiLpn0qequFJ5qrVIwqKQdFxcHUnePVk6/km SOzzAIAw0T2+rvHGaRuN8H1PMX1xF03sMXzzE057zDz42OqW73zWfjAbGOqyY7n6pg OH/TyJ79HAhKg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 063264417DE; Sat, 11 Nov 2023 23:52:40 -0500 (EST) Received: from pastel (unknown [45.72.227.120]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D2B731202A1; Sat, 11 Nov 2023 23:52:39 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference. In-Reply-To: (Alan Mackenzie's message of "Sat, 11 Nov 2023 22:48:43 +0000") Message-ID: References: Date: Sat, 11 Nov 2023 23:52:38 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.023 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > In lisp/emacs-lisp/bytecomp.el (byte-compile-let), when the following > form (from jit-lock--debug-fontify): > > (let > ((beg pos) > (end (setq pos > (next-single-property-change > pos 'fontified > nil (point-max))))) > (put-text-property beg end 'fontified nil) > (jit-lock-fontify-now beg end)) > > gets byte compiled, the order of evaluating BEG and END gets reversed so > that END gets evaluated first. Sounds like a bug. Do you have some recipe to reproduce it? I looked at the bytecode but it's a bit hard to tell what's going on there, since the var names are lost along the way. > The comment in byte-compile-let: > > ;; Bind the variables. > ;; For `let', do it in reverse order, because it makes no > ;; semantic difference, but it is a lot more efficient since the > ;; values are now in reverse order on the stack. > > , is not true. It can make a semantic difference. So doing the binding > in reverse order is a bug. Note that this is talking about the actual binding operations, which is separate from the computation of the values that are to be given. What this is saying is that (let ((X1 E1) (X2 E2)) ...) can be compiled to varbind X2 varbind X1 since computing E pushes it value on the stack, so after the two "compute" we have the values of E1 and E2 on the stack and we can pop them in reverse order. And indeed it should make no difference if we do the `varbind X1` before or after `varbind X2` as long as they get the right value and as long as we don't compute anything which depends on those vars in-between. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 12 01:14:48 2023 Received: (at 67116) by debbugs.gnu.org; 12 Nov 2023 06:14:48 +0000 Received: from localhost ([127.0.0.1]:54964 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r23k7-0005EB-SB for submit@debbugs.gnu.org; Sun, 12 Nov 2023 01:14:48 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60426) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r23k5-0005Dx-PF for 67116@debbugs.gnu.org; Sun, 12 Nov 2023 01:14:46 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r23jK-0001rB-O6; Sun, 12 Nov 2023 01:13:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=jcQmJOL4I4+87rxUsVvIWvVWOZVGl4z9USszzkDrmuY=; b=D0tVA29iYVtU +F3J92J1zVmcUm7orMyXytsP/XgWikjjtZ+MawXidiiKkooJX06dpqRTyVE8cjd1ECCU7LXjK1y2x VYnYdwBnw95yIXTZ8+YjAdZEH6vvfV8xTXjjIBzPVEhgbRopm0eSv1dG4lXQFDHiJ7Y3ms6YTCcW2 jTeBHzxu6YQu/zvyqJK1RBQ25lZBJ4t/mucdwvQjXpb0e6rphBQdjbOUdXRV+56yXLK+H3pg2m9vx XQmKjoy3OHHu00Y9dmU4ddjSt4smZTznz2qaRC0pwmQ8bdM89LJrKOAE+OeyNvt7C7LD4D8BMvmSN M8iw9qNWWAWcFlVoH5F1mg==; Date: Sun, 12 Nov 2023 08:13:39 +0200 Message-Id: <83r0kvv6r0.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#67116: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference. References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67116 Cc: 67116@debbugs.gnu.org, acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 67116@debbugs.gnu.org > Date: Sat, 11 Nov 2023 23:52:38 -0500 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > > In lisp/emacs-lisp/bytecomp.el (byte-compile-let), when the following > > form (from jit-lock--debug-fontify): > > > > (let > > ((beg pos) > > (end (setq pos > > (next-single-property-change > > pos 'fontified > > nil (point-max))))) > > (put-text-property beg end 'fontified nil) > > (jit-lock-fontify-now beg end)) > > > > gets byte compiled, the order of evaluating BEG and END gets reversed so > > that END gets evaluated first. > > Sounds like a bug. It does? I always thought that the order of evaluation in a let form is unspecified, and in practice I had several bugs of exactly this nature, which I fixed by using let*, as expected. Why on Earth should we require any particular order of evaluation in a let form?? From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 12 09:22:27 2023 Received: (at 67116) by debbugs.gnu.org; 12 Nov 2023 14:22:27 +0000 Received: from localhost ([127.0.0.1]:55253 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2BM3-0006y4-6w for submit@debbugs.gnu.org; Sun, 12 Nov 2023 09:22:27 -0500 Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]:49421) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2BLx-0006xn-M3 for 67116@debbugs.gnu.org; Sun, 12 Nov 2023 09:22:26 -0500 Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-507973f3b65so5082343e87.3 for <67116@debbugs.gnu.org>; Sun, 12 Nov 2023 06:21:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699798895; x=1700403695; darn=debbugs.gnu.org; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:sender:from:to:cc:subject:date :message-id:reply-to; bh=igvfhSed5PrxblQd0bJ9i+HhHgFideWKuf6TfErTgzM=; b=L/70ScNcnVcnelQReut0j2nYibRXVgYnfqjqunpWUb068Eo/y/DsdYsJFBVZ2k/WXR widlURc9g0ZHHlEpQQzqHE0fgxlsuhHdGfjkKLJ3O6BrlWwhee70a8gaK4KzrK0siEau rc6BRZCSH+fKc2E7nXLsYREL/k5p8d1iftq9PRzChZnlgv1fB62U1/q7nj1mE6fVY5ms r+blTxDdMU0OYX+5VfOVz5oBaoVzso4zASinj3/IS2a+JOBIhhzuQ6rirDu8OV8Uo3e/ TLWUW8sbDWc7gPlyzp6tE0sMTShtr7ojM7HZkkzeDcU0UkKNpUlT9P9TuQXDSVxNkjdD x41g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699798895; x=1700403695; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=igvfhSed5PrxblQd0bJ9i+HhHgFideWKuf6TfErTgzM=; b=lEUxSjtLkaEYBVQpxE3OcnRlhE2qLXMTxQDonMJnH6dRCsdcO3H4hbanyzyjfcTvtU MRuf4j3MyNwklMj0IGzGFFyC0aYXh6Osg3HmxLuCUWqdV9pPILqCW4+w0vDoCpefNuAn 14EK7RMptr+3lL+6Lq74xN9JysGQtFowT7qW/JWtnhduQ/H3aJJda7n3ZF/5HsBgqYWv TofJ+Jju/SDadKQMeUvmSNybfNptu1j+RKizqrISniMPgG4iOumcJiQm6EtJrejXNFIf JlvZhiiW6CPXSQzWP4kNI5iPw3aGK1WevSaNg502zsfPN7g1Ghq8y0JcM/HdfE4oGT61 jrBA== X-Gm-Message-State: AOJu0Yxjsd35Q9k6guThciC0jeK4gV1OA54fdaQJPVRVxZt6glLPc4qF 5vbZFctPsm89b9n1ZCNdDLg= X-Google-Smtp-Source: AGHT+IHrKw0lcfPmqooEDcTTfLHnCBi+B1O0TjK+SNRhdhe/fnjvWq2myUXA8ptilJmBEke+9noDGw== X-Received: by 2002:ac2:4426:0:b0:509:fc7:8853 with SMTP id w6-20020ac24426000000b005090fc78853mr2468153lfl.12.1699798894453; Sun, 12 Nov 2023 06:21:34 -0800 (PST) Received: from smtpclient.apple (c188-150-165-235.bredband.tele2.se. [188.150.165.235]) by smtp.gmail.com with ESMTPSA id h6-20020a056512054600b00504816564c7sm631602lfl.104.2023.11.12.06.21.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2023 06:21:33 -0800 (PST) From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: bug#67116: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference Message-Id: <2324648E-F860-4D57-A7A9-CF0F4F9DB57E@gmail.com> Date: Sun, 12 Nov 2023 15:21:32 +0100 To: Alan Mackenzie X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 67116 Cc: 67116@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > (let > ((beg pos) > (end (setq pos > = (next-single-property-change > pos 'fontified > nil (point-max))))) > (put-text-property beg end 'fontified nil) > (jit-lock-fontify-now beg end)) >=20 > gets byte compiled, the order of evaluating BEG and END gets reversed = so > that END gets evaluated first. Since the value for END contains (setq > pos ...), BEG gets this updated value of POS rather then the original > intended value. No, the generated code looks correct. Do you have any reason to believe = it's not? (Of course I always blame the compiler first. It's programmer = tradition!) From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 12 09:23:21 2023 Received: (at 67116) by debbugs.gnu.org; 12 Nov 2023 14:23:21 +0000 Received: from localhost ([127.0.0.1]:55257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2BMu-0006zb-Jh for submit@debbugs.gnu.org; Sun, 12 Nov 2023 09:23:21 -0500 Received: from mail.muc.de ([193.149.48.3]:53133) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2BMr-0006zN-VV for 67116@debbugs.gnu.org; Sun, 12 Nov 2023 09:23:19 -0500 Received: (qmail 48842 invoked by uid 3782); 12 Nov 2023 15:22:31 +0100 Received: from acm.muc.de (pd953a91f.dip0.t-ipconnect.de [217.83.169.31]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 12 Nov 2023 15:22:30 +0100 Received: (qmail 22071 invoked by uid 1000); 12 Nov 2023 14:22:27 -0000 Date: Sun, 12 Nov 2023 14:22:26 +0000 To: Eli Zaretskii Subject: Re: bug#67116: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference. Message-ID: References: <83r0kvv6r0.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83r0kvv6r0.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67116 Cc: 67116@debbugs.gnu.org, acm@muc.de, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Sun, Nov 12, 2023 at 08:13:39 +0200, Eli Zaretskii wrote: > > Cc: 67116@debbugs.gnu.org > > Date: Sat, 11 Nov 2023 23:52:38 -0500 > > From: Stefan Monnier via "Bug reports for GNU Emacs, > > the Swiss army knife of text editors" > > > In lisp/emacs-lisp/bytecomp.el (byte-compile-let), when the following > > > form (from jit-lock--debug-fontify): > > > (let > > > ((beg pos) > > > (end (setq pos > > > (next-single-property-change > > > pos 'fontified > > > nil (point-max))))) > > > (put-text-property beg end 'fontified nil) > > > (jit-lock-fontify-now beg end)) > > > gets byte compiled, the order of evaluating BEG and END gets reversed so > > > that END gets evaluated first. > > Sounds like a bug. > It does? I always thought that the order of evaluation in a let form > is unspecified, and in practice I had several bugs of exactly this > nature, which I fixed by using let*, as expected. No. The order of _evaluation_ is specified as top to bottom. The order of _binding_ is unspecified. Quoting from the elisp.info page "Local Variables": All of the VALUE-FORMs in BINDINGS are evaluated in the order they appear and _before_ binding any of the symbols to them. and a little later on the same page: On the other hand, the order of _bindings_ is unspecified: > Why on Earth should we require any particular order of evaluation in a > let form?? To make the value of a form unambiguous? In any case, we do require a particular order. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 12 09:42:48 2023 Received: (at 67116) by debbugs.gnu.org; 12 Nov 2023 14:42:48 +0000 Received: from localhost ([127.0.0.1]:55302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2Bfj-0007TH-Nw for submit@debbugs.gnu.org; Sun, 12 Nov 2023 09:42:47 -0500 Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]:55778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2Bfh-0007T1-PX for 67116@debbugs.gnu.org; Sun, 12 Nov 2023 09:42:46 -0500 Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-50a80241f39so396286e87.3 for <67116@debbugs.gnu.org>; Sun, 12 Nov 2023 06:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699800119; x=1700404919; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=zZi0WndAY/ylynnYL58bVezhf+vkvyehpKyFPUqbOO0=; b=eCicvQ2jdnsmCeBlhAyBwBRWGeiA4SwRGsBpbWXgx07BnzRl4qC8tAh1+sMn3qwqDA j/rJZaQkDm20BgPrAmbgjm4dsLFE3O1x/x6uDjvMppfiEHPAaieZHnrSNv898hfbOhzf kzFpWNjy0usfWG5tMjNTAUG+u5o0lBQumVeHzqaTlhvhPeucift3/huZ1FsG9uRGo8UE wj9x28pSPFdxyuTVAeuXRLxUtagjx9sE4GgoVRif+R4rwCJHjrHJxg7bkGsba5wBNXH9 jqUPDWPtKkm1IeTFxtbdt5me7gJNHdDL2shPAP/YDdAJSAKIFHOD4sW/Mrv40/+2Ha2R lg8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699800119; x=1700404919; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=zZi0WndAY/ylynnYL58bVezhf+vkvyehpKyFPUqbOO0=; b=rJSUaIm0UZ7H+fSroWxW5uyNG8p/nU0xlArmFuTwsDOfZPZxC1BMt+ox0jTV2nbcA4 zrTYljX6Q9zox6128bWxw5TbieFRFT1aGroLCXNKFdp6zQEIXp7bMM84jxZ+iX3IO4H1 7cXBsgEqQRv+Wjmqvpa9Ulx8FtwfNR8Ou8t5H7SSkJNzNikb42KKrr93H27YWxJZFn7M 3qkKWsdHmrr9iGBHg7L4iIIBEMisAwA0b/Iv6cBEi8CNsXCxjrVsuKKtIjRe7owYx9Hu Sp1WQKj8uuMqwlZldIzIsc6ifzo4Wdzwau29DOS+ukyVViHnTxhyk/c86Xp2/udQrHRs SIpw== X-Gm-Message-State: AOJu0YyImONpp0kTd4qkw3cnIyIPdFiPJqTKAeLJOEACi/pOIfCDxada LP52Z2qojeVA2tQhbrfF8mc= X-Google-Smtp-Source: AGHT+IGig3wTzoz2dx1Djaywon+3OyGnj088I/mwkVUPSrPgbTS8bL5brk2IJGHpQzvQyRohr1DLQQ== X-Received: by 2002:a19:7507:0:b0:509:4559:27a9 with SMTP id y7-20020a197507000000b00509455927a9mr2682754lfe.8.1699800118640; Sun, 12 Nov 2023 06:41:58 -0800 (PST) Received: from smtpclient.apple (c188-150-165-235.bredband.tele2.se. [188.150.165.235]) by smtp.gmail.com with ESMTPSA id c22-20020ac24156000000b005079fa0b1c3sm638791lfi.243.2023.11.12.06.41.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2023 06:41:57 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: Re: bug#67116: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: <2324648E-F860-4D57-A7A9-CF0F4F9DB57E@gmail.com> Date: Sun, 12 Nov 2023 15:41:57 +0100 Content-Transfer-Encoding: 7bit Message-Id: <90BD98E4-1026-4290-9D9F-7A413E670DCC@gmail.com> References: <2324648E-F860-4D57-A7A9-CF0F4F9DB57E@gmail.com> To: Alan Mackenzie X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 67116 Cc: 67116@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > No, the generated code looks correct. Sorry, actually it doesn't. There's a bug here, will fix. Thank you! From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 12 09:55:46 2023 Received: (at submit) by debbugs.gnu.org; 12 Nov 2023 14:55:46 +0000 Received: from localhost ([127.0.0.1]:56452 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2BsI-00084U-3b for submit@debbugs.gnu.org; Sun, 12 Nov 2023 09:55:46 -0500 Received: from lists.gnu.org ([2001:470:142::17]:56794) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2BsC-0007uq-Ly for submit@debbugs.gnu.org; Sun, 12 Nov 2023 09:55:44 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r2BrS-0007wP-2K for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2023 09:54:54 -0500 Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r2BrL-0003fu-Tw for bug-gnu-emacs@gnu.org; Sun, 12 Nov 2023 09:54:53 -0500 Received: (qmail 84687 invoked by uid 3782); 12 Nov 2023 15:54:44 +0100 Received: from acm.muc.de (pd953a91f.dip0.t-ipconnect.de [217.83.169.31]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 12 Nov 2023 15:54:44 +0100 Received: (qmail 22204 invoked by uid 1000); 12 Nov 2023 14:54:40 -0000 Date: Sun, 12 Nov 2023 14:54:40 +0000 To: Stefan Monnier Subject: Re: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit Cc: acm@muc.de, bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Hello, Stefan. On Sat, Nov 11, 2023 at 23:52:38 -0500, Stefan Monnier wrote: > > In lisp/emacs-lisp/bytecomp.el (byte-compile-let), when the following > > form (from jit-lock--debug-fontify): > > (let > > ((beg pos) > > (end (setq pos > > (next-single-property-change > > pos 'fontified > > nil (point-max))))) > > (put-text-property beg end 'fontified nil) (message "jit-lock-fontify-now %s %s" beg end) > > (jit-lock-fontify-now beg end)) > > gets byte compiled, the order of evaluating BEG and END gets reversed so > > that END gets evaluated first. > Sounds like a bug. Do you have some recipe to reproduce it? Certainly! In the code fragment above in jit-lock--debug-fontify, insert the diagnostic line as above. Byte compile this function. Then M-x jit-lock-debug-mode. Now scrolling any (previously unfontified) sections of a buffer will fail to fontify those sections. In *Messages* it can be seen that the printed values of BEG and END are identical, hence the call to jit-lock-fontify-now does nothing. > I looked at the bytecode but it's a bit hard to tell what's going on > there, since the var names are lost along the way. > > The comment in byte-compile-let: > > ;; Bind the variables. > > ;; For `let', do it in reverse order, because it makes no > > ;; semantic difference, but it is a lot more efficient since the > > ;; values are now in reverse order on the stack. > > , is not true. It can make a semantic difference. So doing the binding > > in reverse order is a bug. > Note that this is talking about the actual binding operations, which is > separate from the computation of the values that are to be given. > What this is saying is that > (let ((X1 E1) > (X2 E2)) > ...) > can be compiled to > > > varbind X2 > varbind X1 > since computing E pushes it value on the stack, so after the two > "compute" we have the values of E1 and E2 on the stack and we can pop > them in reverse order. It seems apparent that the computations are being done in reverse order, too. That can be seen in the above *Messages* output as well as in byte-compile-let in bytecomp.el: (dolist (var (if is-let (reverse clauses) clauses)) (unless is-let (push (byte-compile-push-binding-init var) init-lexenv)) (let ((var (if (consp var) (car var) var))) (if (byte-compile-bind var init-lexenv) (pop init-lexenv)))) .. (reverse clauses) happens before the code for any of the value forms gets generated. > And indeed it should make no difference if we > do the `varbind X1` before or after `varbind X2` as long as they get > the right value and as long as we don't compute anything which depends > on those vars in-between. Yes, that is all true. But the byte compiler generates code which does the _evaluation_ of the values in the wrong order, according to the description of let on page "Local Variables" of the elisp manual. This is a bug in either the byte compiler or the documentation of let. I would tend towards the first of these alternatives. Whatever, that let in jit-lock--debug-fontify would probably be safer if it were a let*. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 12 11:50:50 2023 Received: (at 67116) by debbugs.gnu.org; 12 Nov 2023 16:50:50 +0000 Received: from localhost ([127.0.0.1]:56852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2Dfd-00038X-GP for submit@debbugs.gnu.org; Sun, 12 Nov 2023 11:50:50 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54711) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2DfY-00038A-06 for 67116@debbugs.gnu.org; Sun, 12 Nov 2023 11:50:47 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 38F47440F32; Sun, 12 Nov 2023 11:49:57 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1699807796; bh=Bl5JKfSAz3l7bW25Y8/Ly/0xhbd7fy1uOW1wyiqqfcs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LybXKc2ic0K203lbCK3oXJXzM2MWLRuJ17Okhz/Gw4LM8ulmQEoDJJpR9ZIk/NAw4 ba+gDqxQbgG9HUzSoEZqZhA41Og3L9vsUw99vcUgoP07t9rDuakN9VxyoMOzVLIGLD 0GXc20uAliBE88Op0u/SZXEM6894wPPlgkkAZBHJzNbKgWZU9PTUqc5bJwCXzTVj+5 N8lt7mnEtuAy2eJ4gudfgydU/nMci3s8xaOejsBIw8SSTqeEHIirNppQi/P0U36VVS zoA32ckDXUXEeR3pHWEPocDRJ9RxYvXkNY7bmMrOMEc+hXHWaiNm581mQAB6SxdUix uN6T3lS9QO/AQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3859C440876; Sun, 12 Nov 2023 11:49:56 -0500 (EST) Received: from pastel (unknown [45.72.227.120]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 11E1712034F; Sun, 12 Nov 2023 11:49:56 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#67116: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference. In-Reply-To: <83r0kvv6r0.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 12 Nov 2023 08:13:39 +0200") Message-ID: References: <83r0kvv6r0.fsf@gnu.org> Date: Sun, 12 Nov 2023 11:49:55 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.023 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67116 Cc: 67116@debbugs.gnu.org, acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> 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 From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 12 12:07:26 2023 Received: (at 67116) by debbugs.gnu.org; 12 Nov 2023 17:07:26 +0000 Received: from localhost ([127.0.0.1]:56865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2Dve-0003Xi-NU for submit@debbugs.gnu.org; Sun, 12 Nov 2023 12:07:26 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63794) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2Dvc-0003XM-Ph for 67116@debbugs.gnu.org; Sun, 12 Nov 2023 12:07:21 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 55756807A7; Sun, 12 Nov 2023 12:06:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1699808788; bh=EQ9AVH5Zr6wEgG4EBBaQFgD6pzvuosPDKW0SWHItA4k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QXEcMX3RUzDZVWmNGf3aZLm19ObJ60WR4gUu026Xdd/gn+1Pv7AaIPcrLTtUmH+Bp ghoVv7Jc2ZqFHPbc0QEOJfnSFbNmBZntuxXj+PXv+zy8tuiL8Su27tXpxk2XNP0pGn fWc1TriQ47HKL+VuIzRFrN9qoGu8KFufMuBhNskoqF9oAfQ97uePMnN3FqdfYwLSq0 fkT6HWomF+r1BPg3Veqx0eMGYWsVM+ZPRkCVwhGLPdOEECL80VkTXIsbfBqtg1pgLZ KqtRNDVtbgmYzVjfxKY9XM2CKEKvZ6z1JwYzlnhr28m3XiOTz4NL5ZHBYn0JchRGOQ QK2AmxOefXSlA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3B4CB80578; Sun, 12 Nov 2023 12:06:28 -0500 (EST) Received: from pastel (unknown [45.72.227.120]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 12A1412044D; Sun, 12 Nov 2023 12:06:28 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference. In-Reply-To: (Alan Mackenzie's message of "Sun, 12 Nov 2023 14:54:40 +0000") Message-ID: References: Date: Sun, 12 Nov 2023 12:06:27 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.016 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67116 Cc: 67116@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> Sounds like a bug. Do you have some recipe to reproduce it? > Certainly! In the code fragment above in jit-lock--debug-fontify, > insert the diagnostic line as above. Byte compile this function. Then > M-x jit-lock-debug-mode. Now scrolling any (previously unfontified) > sections of a buffer will fail to fontify those sections. In *Messages* > it can be seen that the printed values of BEG and END are identical, > hence the call to jit-lock-fontify-now does nothing. Hmm, indeed, thanks. Apparently Matthias already found the problem, I'm looking forward to his explanations. >> since computing E pushes it value on the stack, so after the two >> "compute" we have the values of E1 and E2 on the stack and we can pop >> them in reverse order. > > It seems apparent that the computations are being done in reverse order, > too. That can be seen in the above *Messages* output as well as in > byte-compile-let in bytecomp.el: > > (dolist (var (if is-let (reverse clauses) clauses)) > (unless is-let > (push (byte-compile-push-binding-init var) init-lexenv)) > (let ((var (if (consp var) (car var) var))) > (if (byte-compile-bind var init-lexenv) > (pop init-lexenv)))) > > .. (reverse clauses) happens before the code for any of the value forms > gets generated. AFAICT "the code for any of the value forms" is generated by `byte-compile-push-binding-init`. When `is-let` is true, the above loop does not call it at all, it only emits the code which does the `varbind` thingies. When `is-let` is true the calls to `byte-compile-push-binding-init` are performed just before this loop (and non-reversed). Maybe having written this code I'm unable to see what it actually does instead of seeing what I want(ed) it to do, but my impression is that if it really does it in the wrong order, we'd have noticed a long time ago. My crystal ball doesn't want to talk to me today, but my hope is that it's a bug in something like our new-ish variable/constant-propagation optimization. > This is a bug in either the byte compiler or the documentation of let. > I would tend towards the first of these alternatives. +1 Stefan PS: BTW, Alan, thanks for putting me in `Cc:`; even better would have been to put me in `X-Debbugs-Cc:`. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 12 14:33:23 2023 Received: (at 67116) by debbugs.gnu.org; 12 Nov 2023 19:33:24 +0000 Received: from localhost ([127.0.0.1]:57039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2GCv-0007LY-Mr for submit@debbugs.gnu.org; Sun, 12 Nov 2023 14:33:23 -0500 Received: from mx0b-00069f02.pphosted.com ([205.220.177.32]:19216) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2GCq-0007LM-Mh for 67116@debbugs.gnu.org; Sun, 12 Nov 2023 14:33:21 -0500 Received: from pps.filterd (m0333520.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3ACJVdSC032319; Sun, 12 Nov 2023 19:32:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2023-03-30; bh=3FxGpEvDdIWw9qWLaHo821uh1Gda8fr6bTU8VMMzHCY=; b=2kHD8XtbrKgx2V8W0/ZBxN5FRDlbBs3hbWU8MHkkj+AGTNdyBF3w/9VQ50dMTSwF7eeK t8vgKwT23v1ff0L37fdTjUNCabF2DioU3l3SP9Ja1T8NsVCGtbbDaeqHJGFUWOHA9drq 9ymUJ4I4PDpZdKwAsP1CIgv+ZhBHIjaS9V1CxpKoasnsPfBXRbMNMdbJfzm0PqeKE0F8 dSp4PNHUjeGbz5MJxQ2YwZlRFN1XjP6i9eo04k6gTGlmwSvksZIH5DLty8W+QbcI2SYX 8dkO9DdfgCqzIvUScreeUPq5efL3PS5JI7r3ajkg6dI1i9QlTyYF0Zk5WYOBCc/1c+LH LQ== Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta01.appoci.oracle.com [138.1.114.2]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3ua2mdhp56-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 12 Nov 2023 19:32:34 +0000 Received: from pps.filterd (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 3ACH0KUq020759; Sun, 12 Nov 2023 19:32:33 GMT Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2040.outbound.protection.outlook.com [104.47.66.40]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3uaxgxxjvf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 12 Nov 2023 19:32:33 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Otxzge/RMIvWhqyAg5OvEvYSkarvD1t7YP6H6B+BBVXcwfwO+b0oqx/GNtLC5KWtR9tTV6EWLeh/thftGYKXCDsT6eXTbDngU72BuuYEDL8Cu8asmMzhlNi/YyAO95c8IahY87vd2q2nwLV1fOz101UbQxhQh3bCJBs2sNsL58OxkO+LSXyra8zahActdawDWC8XQgw4zZ+83J86jYNGG8ggYTFCgvvPj/SgAS84NP9lnNefdshYjf+peUsGlkbKOH/QNc6ACITC6t0u7NCiifYotVuU8aiyKa9cZgfRsMq5jhuiKx3iok1QgM0OLt/FJeB3u0cof8D4zMBlVgu1EQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=3FxGpEvDdIWw9qWLaHo821uh1Gda8fr6bTU8VMMzHCY=; b=CdrmRfNIn59ahXEeZb9mjBnnFX9kjbEYvUg/nwnUhDUUsEAWQpeV6GcBg7sWOeuEYa33rZJ3MC4lPeDLqbCFPSIq9QBMZb+9OzzPPCty5FLbrLVx8HFl9yu2hg6LEgJ+vFwJlbrI/bZFaKVq4cOJ1wTCkbAzm+J8152upfYRIZeRBMAib+oZOucvrjeMqHn+a+UUn+xVqL74rcmRtCWozKXIJJx4b48Npil4C5ioKBhHkZWNB9gEYZLAdUietl7tEJHbPqQYJOyyJvkUPSdcIYyHxlCCMfPDw0YlI1DlgSs/hmRwoeA9J6tbmasaitTvPUwl/wzWirH2xkpGwiGavw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3FxGpEvDdIWw9qWLaHo821uh1Gda8fr6bTU8VMMzHCY=; b=UCp9SgqA/RAvNsz10uuF7iJQaCY0Imv/RJP3/G2UdTePeNc+RRk9MUlb32B9ldPyWe9N09WA9cLofE+eonxP95mkWn8jd81EMmCNXuV6Y5xNFI508bVxqWwD1/R+tnXv9fAJBwgzEi9qVc4A4khZgqKkCK6X3+rb7E7aT0yrRN0= Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19) by CH0PR10MB7535.namprd10.prod.outlook.com (2603:10b6:610:187::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6977.29; Sun, 12 Nov 2023 19:32:24 +0000 Received: from SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::3b4c:a669:c229:47b4]) by SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::3b4c:a669:c229:47b4%6]) with mapi id 15.20.6977.028; Sun, 12 Nov 2023 19:32:23 +0000 From: Drew Adams To: Alan Mackenzie , Eli Zaretskii Subject: RE: [External] : bug#67116: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference. Thread-Topic: [External] : bug#67116: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference. Thread-Index: AQHaFXPYkuQlM3X6PkGhmXnLd7W0bbB3Elug Date: Sun, 12 Nov 2023 19:32:23 +0000 Message-ID: References: <83r0kvv6r0.fsf@gnu.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SJ0PR10MB5488:EE_|CH0PR10MB7535:EE_ x-ms-office365-filtering-correlation-id: 49fea385-9444-4239-e82e-08dbe3b6182c x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: U7lFyIFx+3c4V22GWD4NTAyFwzymvmibh4sOK58rE8oRMQTCPut3z4sKCDDxRbBWn0kj4xetWWCp8lt89KSckh8WHpYb7CFgTBB0/2/OgkDN3N3h/1+6JDarFIh5Tob4/Kz8aMGlLx/UMDy+sZXNtsmVOV8KOx7DWOrzRr5S0Y7D7z7yVxBIrzFjSxreR5nwvmMeKukxWWVKZqKUl5FHztiCkQIYR0IFndAvRy8BL3ReHhe6+o52PZZ5z/xrd1w02NyRiEd1PByLaqWYox/rPwPRAbgnotoUNw0Y8ZAcbKwhC3gW/LrRn6KifSTtDWaOZDg3ulU9goM6AIId/ZvCRNv3bXj9aK7+21KH6OfPQW9QjpOAu6sX11OMTTTPidpYDXLJ5L61Pwn0qEdooP7+xmOOPtlkr64r2l397xz8rKeunvEGFFJNmB9KFd5v1CZtrm1VLkRLktqU388md0EgTu4FJg+Q+VAMtv9ctbIWJL4zMozFdiIUk3FnZMZWwGZDqacbkUiKMRWLW1StzlsKKtxoL+qqz2EEUh9u1Tv1f0zlLTU7rtHOKVyfX7lI6Bv7FRpe8IHlQk6qD8L+Nvsy7UE/918fe8VH/VIm/BXc3Hi4K6GbWavSSw8tGMQNwHbp x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR10MB5488.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(39860400002)(366004)(376002)(346002)(396003)(136003)(230922051799003)(451199024)(64100799003)(186009)(1800799009)(26005)(6506007)(7696005)(71200400001)(9686003)(83380400001)(44832011)(5660300002)(4326008)(8936002)(8676002)(52536014)(41300700001)(2906002)(966005)(478600001)(110136005)(54906003)(64756008)(66446008)(66946007)(76116006)(66476007)(66556008)(316002)(122000001)(86362001)(33656002)(38100700002)(38070700009)(55016003)(154513002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?VdkfYYWsTPw6BaU9du4DaEL8N4ydP1NdVzRr78Zua1VLJA1nG2kfEh0+LaKV?= =?us-ascii?Q?oK1cTk2WBd3eL4ERk3jtoXzLoNwgPvHEd5PdAvbMtT3SgyrOIGm7MFd3VK9b?= =?us-ascii?Q?gNQdQSriyCB5PYDG3n1jfCoO5qe+1q0j6sLU16j4MhGXWUDwZoPv7y4qAtuT?= =?us-ascii?Q?0eLFII7HNqoLVh+cxh8p1dfCvlJXiJRzjBitKE34agfAaJsom4nxK34peH7z?= =?us-ascii?Q?zdSdcg92+2F1FlRuWOwkDd6zA83IEUNV3/Bzx3b7uGhpdFwD61sMAkI9ryD5?= =?us-ascii?Q?93EkkoEbbdNSsQCi+DDTiTuscjIG/J8qlXXNWzQCFvaMjpqCK+JDwBWxhpfy?= =?us-ascii?Q?DvcNtXz7Qglc+KjMr5pfyfAE+T818RVubw0R2KjWzkPZwYhR7+8nuI544EZz?= =?us-ascii?Q?eFJDtVjoTznMmUM8Aeo0sFqCFeBgcgnEPbKTS22IJJUR1o3RuCtqyLkSSKne?= =?us-ascii?Q?imhGbZQkQhAkpOJYMr2HbzFk8EtWkZLJfEGz/8KZZNqJWl/5awhtAOt98BXU?= =?us-ascii?Q?6UYEgLmUZyK7G+NR7AxPj4wZYe3P+r28hl019At2oo+G+HyMe0kxcCW3FBCJ?= =?us-ascii?Q?QOcJccdj48JNU4+sgn4+4RLrR3gYF+Uqvb6ApgEkxfBID7HS5uwzqKl61fyN?= =?us-ascii?Q?wIYTnWmoiaBLumkXGK8vx6aTsNxJ5XD9P1NzPvmZ8TEXqvx3HJLkTkeasHgZ?= =?us-ascii?Q?h07W04LPkz1SHZ0ZWc54SVKunDWRPSYN7wzFtLM7Xfshvg49Z3sMSxTD3ucb?= =?us-ascii?Q?+rNpACkT8pwD6rmmhw+i6kL9VyA46b1GnQFGhxJn5SBIGB1TjGS3CyeNAwiF?= =?us-ascii?Q?BZ9vBOZpbxwkakVLtQW6TMfUGorS66F6jIWCgYyZGE+lgGMkO9NzmzKvWYKB?= =?us-ascii?Q?V5iDZ0lRAuKkbTs4EgnVWu0PLU8H/SvRhT4lBi1dIo6LxcSvtNEiChEMSwWp?= =?us-ascii?Q?9oPZdcBjjyeMxcwy4irk+FbKbGX4BNl7qPU8A5Kzm/vZ6lggXkPJXQ7s99bX?= =?us-ascii?Q?7VVcjGWJ4lTOUxC8L0nbMvFRyjgGOk8dlK7W71LBHc9Xhi4y8JoYolJmy2pw?= =?us-ascii?Q?63pSLDK6f/1O2231gDzg+kYioMBpfSxWak0HZEtVBQoglh8+P/4uQ1I5cE5v?= =?us-ascii?Q?6Q8YxIWTjSKl05E0GpdjIJH60VOUoE00lCkEUvaEXcz4eijXApKQ1FS9uAMQ?= =?us-ascii?Q?zqDAqUegUyFDQMVGxkHv/B/SGhZVSp8l4mKeABvf055PHRsYd20fm0D3nW3I?= =?us-ascii?Q?pipe9Q7YLCaeVOo07AUH6lvz4rCr/pZMc52jlzQDSYLlAoC0meygCtn/smTs?= =?us-ascii?Q?jP7EZzHhseyyyWA7CfgEhsOxDm33MoENkGUii2RbQd+HPYx3o+kRvxlT7HIv?= =?us-ascii?Q?fVgcvWdq5Uz2b8g5rhzL3/Fi+gfnIttLz2zZFbAe1U2blJngSjsPkTsI5WXp?= =?us-ascii?Q?CTbhCFI9nzyu3xZ2ygJn1V9HFak8r0zr6RX2eZ21aOx5GksAS1hKctENbpQa?= =?us-ascii?Q?euIUPDmxLUtJEx1lYD9lDbw9TSbTZwfHVqm4teoG3S7PrwNDhy4OSCZTJeeJ?= =?us-ascii?Q?S7+GZuBE/B+J+V87eCo6M4G+fTKt9BRR+dB8X65i?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 4JORHHQV29+hoAmyNzElD6NL8wCj/7bD8GFhckUpZkJSOirGYrW0Q8wrZGZPtTGoYEJBwXF9bLkMBbDuy0IbvwUFKpPmhWvDDaLvizwJrFAcr/yDxcGHYrI/Gl5Y2xqlvfiHESHaRvwL+zl2v/HJP8RJXA2lmMkiY+7trrhN+FT3YhczUfeOdSzYxp6DLT3mWsatt/qg0QlDr7o9r5oe9c/sv/PM6OGQ9fHQ+E83g/1VCQvvBG4NzL/Aw/nT5W7Q5se1HuFvVxKyXACFDtacjX6YIXCjhxIvousO2q3Oc/7ZBqit0o/r7OrlrFsb/RpbWVyBLW9voBAwNfMGcJV1Y98CyZGhQ1VMhK+wupKbVRKwuz2YkeDyrwGZ/zmchnBQMObZch6pvZPMup+USNrBU5EetNCZ03gTALLqMortw0F+63vUnH0wfnRmwjsQ7m4KW699oQXCzm9uf5lxB4ujC469PiWQ0jbGpAB2dHog7GA7DNuNfBqjskutyL9mXahD8HuiuWGyKdIX/Uo0RY9sdeGg0Ts7WdEvYrwUpp65GISVQ5qmZI85SqaFMSvSqmqrrKE1OpOoAxHw9TLN+GEQF5ud3TC/YuRYUF52W7lJasItz+vYRHQCI7e2G7+LCKNKQgVrJo5t3BB3IIoYd2DQNg81A9cHQP8+futgIi09lDbK9iPz2WiHlhJu+gQrokZwogT/p7dokQicesqfiRm6p7pB/g94l6A96ElDYFNNtaHbzOv6RWwwoLqQyUiuQFw5uS9uV4lwhpqFxzE7IOqyTxiEksDtubkN6r24hpNgJnmu9+2jVBmKkm3MzVy8U50coHienDE6XNIIbUZ08VuvNl2MXW2uarY9r2HZmvvwnfg= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5488.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 49fea385-9444-4239-e82e-08dbe3b6182c X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2023 19:32:23.2072 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AghM7arvzyJj4k4GiWjgzF7oRZZAepJXNRYGIq4rKyT9+Mn07SdF/94bK7XHqn3Kfok/7Z28nrsyHJALXRs41w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR10MB7535 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-11-12_18,2023-11-09_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 bulkscore=0 malwarescore=0 phishscore=0 mlxlogscore=537 adultscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311060000 definitions=main-2311120170 X-Proofpoint-GUID: 0qldofGyLEL7tIwG_6OhYd_ssRwdbUhU X-Proofpoint-ORIG-GUID: 0qldofGyLEL7tIwG_6OhYd_ssRwdbUhU X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 67116 Cc: "67116@debbugs.gnu.org" <67116@debbugs.gnu.org>, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > > It does? I always thought that the order of evaluation in a let form > > is unspecified, and in practice I had several bugs of exactly this > > nature, which I fixed by using let*, as expected. >=20 > No. The order of _evaluation_ is specified as top to bottom. The order > of _binding_ is unspecified. Quoting from the elisp.info page "Local > Variables": >=20 > All of the VALUE-FORMs in BINDINGS are evaluated in the order they > appear and _before_ binding any of the symbols to them. >=20 > and a little later on the same page: >=20 > On the other hand, the order of _bindings_ is unspecified: >=20 > > Why on Earth should we require any particular order of evaluation in a > > let form?? >=20 > To make the value of a form unambiguous? In any case, we do require a > particular order. Yes. And FWIW Common Lisp does the same (which likely means that most other Lisps at that time did the same). first evaluates the expressions value1, value2, and so on, in that order, saving the resulting values. Then all of the variables varj are bound to the corresponding values in parallel https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node83.html From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 13 06:20:20 2023 Received: (at 67116-done) by debbugs.gnu.org; 13 Nov 2023 11:20:20 +0000 Received: from localhost ([127.0.0.1]:57572 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2UzL-0006wF-Nu for submit@debbugs.gnu.org; Mon, 13 Nov 2023 06:20:19 -0500 Received: from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a]:49543) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2UzJ-0006w2-HG for 67116-done@debbugs.gnu.org; Mon, 13 Nov 2023 06:20:18 -0500 Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-507973f3b65so6115385e87.3 for <67116-done@debbugs.gnu.org>; Mon, 13 Nov 2023 03:19:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699874370; x=1700479170; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=pcLSo99MnCtAeA1wdQ/KXsqWugQ6mw6NXOozFKccVek=; b=lL9H4+BnykZxaq6UutkeKr2fisLJPfZ3SYR6YFgN6aykmPPkijtkfPTFdg2kWfkQnE TVB2XkW76QPLVez1KZOkb54x6DpoICYjhn1IUpR5bA0tNVitYdB1ttXjRKlKDs6ovg0N 1tpJHWGfemB0sU8awhbnhqkTjpcIpMJCLbI66Ks2k+ONdLoTsK6EHINFqZ06WLrq8HS3 yBvjABXduoNnyeGivBGv3iOFp8fbobkjgWwE2ivEvCHdWBON4jQXXrhTt+05fCzvISoP QHtD6ZUQIejKrtklMgmXvzHYQsiyTM66YjEXRZaoC9O4ke0DtQf7ubKdkzWrdBbvXj4C uFfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699874370; x=1700479170; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=pcLSo99MnCtAeA1wdQ/KXsqWugQ6mw6NXOozFKccVek=; b=BjpUCmfGKs7WMyN95S13yQc7+Ee974Mgs8+YI1BZow6AUKKy4VbqqJmx10dG64AtJH azNTCSrIK1F2glImxWk4h2vte2zzjqzi/6xVGFN6t/jFwlxXZOpsdeKBAEZXx70kRmgx aN1NUTqeMuDf8WMU6L5mk4TEZg/8B9+7u9qsuAsbScrh+pb13vxwt/Y5/5hMmZkc64IT SuC3EjvxngVRVT0pxgrXYXcC2DPq0L2YbPNZ0eCuPKR89zsP8nfKdUgcMI8q23oV0wVw rrRnHeNLxXgmHEFCDYCiGxuoUX0rwkJ83WG9FMPSX+SEx3GXA8U0qa10ACyHqsReyemN t5uw== X-Gm-Message-State: AOJu0YwDS9+EuPqcz9y2xpt1KC+vI3wvzAnXJ5/lw0T3myKK7VD0cstd 37IUyqZK0Jmdf7UsJ+jCKEU= X-Google-Smtp-Source: AGHT+IHJ8cnQZnMg36FY6RJlAZtFbCZVorUlP+L//y3aUDNOnT1IARTvZXkHcfcC4bPp83CT1ZTsHA== X-Received: by 2002:ac2:434d:0:b0:508:26b2:7803 with SMTP id o13-20020ac2434d000000b0050826b27803mr3876832lfl.69.1699874369568; Mon, 13 Nov 2023 03:19:29 -0800 (PST) Received: from smtpclient.apple (c188-150-165-235.bredband.tele2.se. [188.150.165.235]) by smtp.gmail.com with ESMTPSA id be20-20020a056512251400b00507f0d2b32bsm942500lfb.249.2023.11.13.03.19.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2023 03:19:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: Re: bug#67116: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: <90BD98E4-1026-4290-9D9F-7A413E670DCC@gmail.com> Date: Mon, 13 Nov 2023 12:19:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2324648E-F860-4D57-A7A9-CF0F4F9DB57E@gmail.com> <90BD98E4-1026-4290-9D9F-7A413E670DCC@gmail.com> To: Alan Mackenzie X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 67116-done Cc: 67116-done@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > There's a bug here, will fix. Now fixed on master. I'm very pleased that you reported this bug. (Of course it didn't have anything to do with order of evaluation at all = but you already understood that.) I didn't do a deep analysis of what code was affected by the bug but = measuring changes in the bytecode size, which is usually quite good, = only two places turned up: jit-lock--debug-fontify, which you already = noticed, and c-forward-sws in cc-engine.el, where the code (c-put-in-sws rung-pos (setq rung-pos (point) last-put-in-sws-pos rung-pos))) was probably affected here. (Obviously the bug was out to get you = personally, Alan.) From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 13 08:15:12 2023 Received: (at 67116) by debbugs.gnu.org; 13 Nov 2023 13:15:12 +0000 Received: from localhost ([127.0.0.1]:57658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2WmW-0004RT-FM for submit@debbugs.gnu.org; Mon, 13 Nov 2023 08:15:12 -0500 Received: from mail.muc.de ([193.149.48.3]:21183) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2WmU-0004RC-Ox for 67116@debbugs.gnu.org; Mon, 13 Nov 2023 08:15:11 -0500 Received: (qmail 17462 invoked by uid 3782); 13 Nov 2023 14:14:22 +0100 Received: from acm.muc.de (pd953af3b.dip0.t-ipconnect.de [217.83.175.59]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 13 Nov 2023 14:14:22 +0100 Received: (qmail 7173 invoked by uid 1000); 13 Nov 2023 13:14:21 -0000 Date: Mon, 13 Nov 2023 13:14:21 +0000 To: Mattias =?iso-8859-1?Q?Engdeg=E5rd?= Subject: Re: bug#67116: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference Message-ID: References: <2324648E-F860-4D57-A7A9-CF0F4F9DB57E@gmail.com> <90BD98E4-1026-4290-9D9F-7A413E670DCC@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67116 Cc: 67116@debbugs.gnu.org, acm@muc.de, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Mattias. On Mon, Nov 13, 2023 at 12:19:27 +0100, Mattias Engdegård wrote: > > There's a bug here, will fix. > Now fixed on master. I'm very pleased that you reported this bug. > (Of course it didn't have anything to do with order of evaluation at > all but you already understood that.) Thanks for the fix! Yes, Stefan M. was right, here. I think it was caused by a (relatively) recent optimisation introduced into the compiler. > I didn't do a deep analysis of what code was affected by the bug but > measuring changes in the bytecode size, which is usually quite good, > only two places turned up: jit-lock--debug-fontify, which you already > noticed, and c-forward-sws in cc-engine.el, where the code > (c-put-in-sws rung-pos > (setq rung-pos (point) > last-put-in-sws-pos rung-pos))) > was probably affected here. (Obviously the bug was out to get you > personally, Alan.) I'll have a look at that, sometime. It somehow doesn't feel particularly urgent at the moment. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 13 21:57:05 2023 Received: (at 67116) by debbugs.gnu.org; 14 Nov 2023 02:57:05 +0000 Received: from localhost ([127.0.0.1]:59753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2jbs-0004Uz-LX for submit@debbugs.gnu.org; Mon, 13 Nov 2023 21:57:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49636) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r2jbp-0004UU-ME for 67116@debbugs.gnu.org; Mon, 13 Nov 2023 21:57:02 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r2jb3-0007nW-MU; Mon, 13 Nov 2023 21:56:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=ICRTxH1Qc5N4Qd9JvN0q6NHLmV7yvVI0tZBBEbaNL4Q=; b=aJg6d5eSfIk3 1ezDsTMNw6/CEzFxcPJ853NTr5CMbul2qjDtG8MwVlqrDi3dhfgO7A/SXW41iKJIZb5UxoiILpmvg ueG+F1/D+uCMd0b/TDbzgSENwkipgWM6XSd8OMjImzgl2HeRTBi2oxXvIIB5YWER85sAH1qfHLNLv i9R0vPglSDkovUT7FbR5pIekCOFDz8/x5YjGp8Jx096yVinENnm1k7nRd8lc2TX3NhAV+E5kQ15r0 Yr2PyE+ZJSVjJn4cDlhfw3ivg8osd3CIWQFYEoIPJf29+EmpSLK8JLAglRtehQTtlCnXqszBI7ukq mN55MBC3SYlNuNdc5/Cakw==; Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1r2jb3-0005jf-DH; Mon, 13 Nov 2023 21:56:13 -0500 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: Drew Adams In-Reply-To: (message from Drew Adams on Sun, 12 Nov 2023 19:32:23 +0000) Subject: Re: bug#67116: byte-compile-let: reversing the order of evaluation of the clauses CAN make a difference. References: <83r0kvv6r0.fsf@gnu.org> Message-Id: Date: Mon, 13 Nov 2023 21:56:13 -0500 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 67116 Cc: 67116@debbugs.gnu.org, acm@muc.de, eliz@gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > first evaluates the expressions value1, value2, > and so on, in that order, saving the resulting values. > Then all of the variables varj are bound to the > corresponding values in parallel That is what `let' did in MacLisp, and what it does in Emacs Lisp too. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From unknown Fri Aug 15 16:00:23 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 12 Dec 2023 12:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator