From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dave Goel Newsgroups: gmane.emacs.bugs Subject: bug#66940: Dynamic scoping is all weird now? Date: Mon, 6 Nov 2023 01:57:05 -0500 Message-ID: References: <87ttpzhcmd.fsf@web.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000004dbcff0609765da7" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9114"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Gerd =?UTF-8?Q?M=C3=B6llmann?= , 66940@debbugs.gnu.org To: Michael Heerdegen , Dave Goel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 06 07:59:08 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qztZj-0002EU-Od for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Nov 2023 07:59:07 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qztZ7-0004MQ-Gk; Mon, 06 Nov 2023 01:58:29 -0500 Original-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 1qztZ4-0004Lo-Od for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2023 01:58:26 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qztZ2-0001Kk-Tj for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2023 01:58:25 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qztZd-0006I4-SV for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2023 01:59:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dave Goel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Nov 2023 06:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66940 X-GNU-PR-Package: emacs Original-Received: via spool by 66940-submit@debbugs.gnu.org id=B66940.169925388224113 (code B ref 66940); Mon, 06 Nov 2023 06:59:01 +0000 Original-Received: (at 66940) by debbugs.gnu.org; 6 Nov 2023 06:58:02 +0000 Original-Received: from localhost ([127.0.0.1]:38553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qztYf-0006Ge-H8 for submit@debbugs.gnu.org; Mon, 06 Nov 2023 01:58:02 -0500 Original-Received: from mail-il1-x133.google.com ([2607:f8b0:4864:20::133]:53549) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qztYd-0006GL-FE for 66940@debbugs.gnu.org; Mon, 06 Nov 2023 01:58:00 -0500 Original-Received: by mail-il1-x133.google.com with SMTP id e9e14a558f8ab-35931064a3bso16585695ab.3 for <66940@debbugs.gnu.org>; Sun, 05 Nov 2023 22:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699253836; x=1699858636; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=L5vWnBULFW29XFxLgTcw7xlp+LT5BiPPt05oxOpBFTw=; b=QY6CARhuu3RUD5ia7iPpPwx20si2GG7JHLvYOXVefHwaQ1cRmhs+u7j+9Oc1lkH41F g/ekdQjlN/mqy/1P2ejDzO/SZnc837tnX7DvcL5otHuvqoeG8Fh/AWcNbd0d18WigQAV 741q3ift1lUwJXStJbPFsjZlHAirOCNlyPJXFjNuESt6Hr163pgotLQ8uzT/MI02gDcW au3poXddw/fQMPqwVGNjUikK50xrVsRU+wlA/ZfLWi8HWe1onyns9O6mKNoqPET5FL+O Xc2mvyCdn9VcfL7DoMPjb1JGmysXYu9S9VmoMn5o3VGPnpYMkh/I8dFCr6uOKKv/lSk1 j1Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699253836; x=1699858636; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=L5vWnBULFW29XFxLgTcw7xlp+LT5BiPPt05oxOpBFTw=; b=A6S3hWyr7gKWXzXxfrWQZQ6ZPEpp1f2y3tQbXnt+8xV9OICazocWRhnpwe/cURFxOm fZXLWvfU/L/zjQzx/d/M1FO5mnxAngF+0rFnyWRtHeKaloJsRTltDI6VLTJexZfH414L EPZY+9rSFtmeyRWz/OxShaWvJ+bzJqhAaJOyjrpIoFha8ky0p+Z90qNtVSigaACk2siW QSxcHVOm01rlBhH1f514XDHNzyM+RIWr+mJfkmGrm5b3KWGv4t6z6BoBWdpE/yTwdHZn hYNMe5FSWVVJbIKO33E6yqad+muhMTeiSSNmkqkiIyrddsq5GTXSbv7eQH42NcTb9L4x Oiaw== X-Gm-Message-State: AOJu0YzqAO2UhsVUfzDPKtLHzUy9acRYYmoXI+54NAzcshIneOjL8HfN c0iQxVZ2tbTnXcWIC6M2I6dD4fHRjR69ozcPkJs= X-Google-Smtp-Source: AGHT+IEnW+0qCz20RIRMmSKKTiQbI8rSRlTlSDf7HbHzi/Ec9TAqqYdLs2NQVnuKlYO28N0xxHg4ryb5r2l/4SyvQwc= X-Received: by 2002:a05:6e02:1351:b0:359:3fd2:1dca with SMTP id k17-20020a056e02135100b003593fd21dcamr16242319ilr.7.1699253836428; Sun, 05 Nov 2023 22:57:16 -0800 (PST) In-Reply-To: <87ttpzhcmd.fsf@web.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:273858 Archived-At: --0000000000004dbcff0609765da7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Michael, Many thanks for that excellent explanation. One more question - With this, first, let's simplify our example as follows. Let's eval this at the start: (setq lexical-binding nil) Eval it, so we are operating in the old world of dynamic scoping. (let ((ii 1)) (defmacro mac () `(print ,ii) ) (mac)) As you said, with lexical-binding nil, the ii =3D 1 had no effect above. It will use the ii from the runtime environment. So, let's try this - (setq ii 3) (let ((ii 4)) (mac)) It evals to 3, not 4. Per our understanding of dynamic scoping, we would have expected it use the innermost ii? Why does it use the global ii? On Sun, Nov 5, 2023 at 8:52=E2=80=AFPM Michael Heerdegen wrote: > Dave Goel writes: > > > (progn > > (setq lexical-binding nil) > > > > (dotimes (ii 10) > > (defmacro mac () > > `(message "%S" ,ii) > > ) > > (let > > ((old_ii ii)) > > (setq ii 33) > > (mac) > > (setq ii old_ii) > > ))) > > This code has two problems: > > (1) Setting `lexical-binding' in the middle of an evaluation does not > work as you think. Either you eval en expression (like the above) using > lexical binding or dynamical binding. If you change `lexical-binding' > in the middle you might get unexpected behavior. Please set the binding > mode only in the file header, not in the code. In the extremely rare > cases where you really must evaluate an expression using the other > binding mode use `eval' with an appropriate second argument. > > (2) Macro expansion does not work as you think. Most of the time macros > are expanded _once_ in the complete expression and then the result is > evaluated. When you redefine a macro in the middle of evaluating code > using it, most of the time this will not have an effect because the > macro had already been expanded in the following code. > > > > You eval this code once. It works. > > You eval this again. It works. > > The third time, though, it lands you in the debugger. The very same > > code. Why the third time? And, why the debugger? ii is well set every > > time it is used. > > It's not surprising. > > The first time you start evaluating the expression using lexical > binding. Because your code sets lexical-binding to nil, the second time > you actually use dynamical binding completely. > > The third run fails because when `mac' is expanded a variable `ii' is > undefined on top-level, so macroexpansion fails. > > The second run is different: because the first run had used > lexical-binding (more or less completely, since you started the > interpreter using lexical-binding mode), the macroexpander of `mac' is > actually a closure that inherited the value of `ii' from the last > iteration of the first run. Because of that the second run succeeds. > > > The second run redefines `mac' so that its reference to `ii' now means > the dynamical global variable, which doesn't exist. > > So, I think everything indeed perfectly works as expected here. > > > Michael. > --0000000000004dbcff0609765da7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Michael,

Many thanks for that exc= ellent explanation.

One more question -

With this, first, le= t's simplify our example as follows.

Let's eval this at the = start:

(setq lexical-binding =C2=A0nil)


Eval it, so we ar= e operating in the old world of dynamic scoping.


(let ((ii 1))=C2=A0 =C2=A0 (defmacro mac ()
=C2=A0 =C2=A0 =C2=A0 `(print ,ii)
= =C2=A0 =C2=A0 =C2=A0 )
=C2=A0 =C2=A0 (mac))

As you said, with lex= ical-binding nil, the ii =3D 1 had no effect above. It will use the ii from= the runtime environment.


So, let's try this -

(set= q ii 3)
(let ((ii 4))
=C2=A0 (mac))

It evals to 3, not 4. Per = our understanding of dynamic scoping, we would have expected it use the inn= ermost ii?=C2=A0 Why does it use the global ii?


On Sun, N= ov 5, 2023 at 8:52=E2=80=AFPM Michael Heerdegen <michael_heerdegen@web.de> wrote:
Dave Goel <deego3@gmail.com> writes:

> (progn
>=C2=A0 =C2=A0(setq lexical-binding nil)
>
>=C2=A0 =C2=A0(dotimes (ii 10)
>=C2=A0 =C2=A0 =C2=A0(defmacro mac ()
>=C2=A0 =C2=A0 =C2=A0 =C2=A0`(message "%S" ,ii)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0)
>=C2=A0 =C2=A0 =C2=A0(let
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0((old_ii ii))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(setq ii 33)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(mac)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(setq ii old_ii)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0)))

This code has two problems:

(1) Setting `lexical-binding' in the middle of an evaluation does not work as you think.=C2=A0 Either you eval en expression (like the above) usi= ng
lexical binding or dynamical binding.=C2=A0 If you change `lexical-binding&= #39;
in the middle you might get unexpected behavior.=C2=A0 Please set the bindi= ng
mode only in the file header, not in the code.=C2=A0 In the extremely rare<= br> cases where you really must evaluate an expression using the other
binding mode use `eval' with an appropriate second argument.

(2) Macro expansion does not work as you think.=C2=A0 Most of the time macr= os
are expanded _once_ in the complete expression and then the result is
evaluated.=C2=A0 When you redefine a macro in the middle of evaluating code=
using it, most of the time this will not have an effect because the
macro had already been expanded in the following code.


> You eval this code once. It works.
> You eval this again. It works.
> The third time, though, it lands you in the debugger. The very same > code. Why the third time? And, why the debugger?=C2=A0 ii is well set = every
> time it is used.

It's not surprising.

The first time you start evaluating the expression using lexical
binding.=C2=A0 Because your code sets lexical-binding to nil, the second ti= me
you actually use dynamical binding completely.

The third run fails because when `mac' is expanded a variable `ii' = is
undefined on top-level, so macroexpansion fails.

The second run is different: because the first run had used
lexical-binding (more or less completely, since you started the
interpreter using lexical-binding mode), the macroexpander of `mac' is<= br> actually a closure that inherited the value of `ii' from the last
iteration of the first run.=C2=A0 Because of that the second run succeeds.<= br>

The second run redefines `mac' so that its reference to `ii' now me= ans
the dynamical global variable, which doesn't exist.

So, I think everything indeed perfectly works as expected here.


Michael.
--0000000000004dbcff0609765da7--