From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pedro Andres Aranda Gutierrez Newsgroups: gmane.emacs.devel Subject: Re: PATCH: Explicitly show how let works on global-variables Date: Wed, 5 Oct 2022 07:28:18 +0200 Message-ID: References: <83czb8vxdo.fsf@gnu.org> <08f6be68d07b1c3ee3c65f8fb6842eb3@webmail.orcon.net.nz> <86lepvut3l.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000aa3b1f05ea42d912" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11366"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Phil Sainty , Eli Zaretskii , emacs-devel@gnu.org To: Tim Cross Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 05 07:30:06 2022 Return-path: Envelope-to: ged-emacs-devel@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 1ofwys-0002kR-E3 for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Oct 2022 07:30:06 +0200 Original-Received: from localhost ([::1]:59792 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ofwyr-00016R-B0 for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Oct 2022 01:30:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50522) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofwxc-0000Og-7X for emacs-devel@gnu.org; Wed, 05 Oct 2022 01:28:48 -0400 Original-Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]:40811) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ofwxa-0004gS-2f; Wed, 05 Oct 2022 01:28:47 -0400 Original-Received: by mail-ej1-x629.google.com with SMTP id f1so15650490ejw.7; Tue, 04 Oct 2022 22:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=T9QIeFV0TKdjtL2yD02C/6NjdqrSbVII85DiwsuZLs0=; b=GUPsKgE4PsuXRHcstizc/4OWzJMCBEqoFEYcamZPiJqVbb6uqvBmYv67NJkg2AdTTC 2pGh/aR6ihq0WZYeBhNdiQpDLJP/w+bKDtn1G+ke+ffLHd/LjSeQ/VQYcP/mxEfXCIXT I7W/e7A930iET3wJCHUGaOZivPyqGjtu7waFSfbWWYLv/6rce316owYPFPsRIoEoOTOx hoEmpDFn7yzfBCkz5pLv9vPv3pUyTra+wP02/gcix7A63CHbu45fHWW9Vf9GEmrDTDNL LgCBezORVBQjNZao14ybm6xpwfyMG5QN6azd9/rzvex5Ts76biRrpEtd2dAcLTV3jsAb QKvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=T9QIeFV0TKdjtL2yD02C/6NjdqrSbVII85DiwsuZLs0=; b=RVsjtjYVKNJhY6Xy+YsmwXTtYewQ3k4tTBUz6x8iPll4VW4H0OV6LFnb5qqzJDJNqb GtgunOzj68LhDuCiqA7Rz4bNDUK91Eh1WQrglWX/vOSycLDXVtsR7b9ulQjpyxrrWDQ1 UBzsSVCThHxHNzVCCiXebyFZvDMho3QDqRyO3W/geJcNB+wKm9Gngq8L+8104syU3j2y p/aEwcF47Yr32wks8Dw7IDUdLm4rtT6XM9z18tGRl4Wjk4p/Ty7R6MUTsZWpdCdqTUwq eO2CQi8BfbITWjDN7bWuMzkTHEIe+yCl0japbTzTxkZzPy9aVqUhohqNDIfjlO4QPQ3K tdXw== X-Gm-Message-State: ACrzQf2yQZ5subYbYxuRa0HeTC2ygnm3M0DsHw8aViHEIorL2rLw7b2u NJr6T1oufe8Ja0Y/t7xOw/iCOfAvAW/Hup2Tw0UGiKsvoE7p7g== X-Google-Smtp-Source: AMsMyM7Qoq4F5VcGRd45HFBriwsT1TjzuJV8+BW6wk57eqAKsGcNPM8QOZLfWBdnPzBecW7CFbkZiQ+57YtelChCiws= X-Received: by 2002:a17:906:11d:b0:712:abf:3210 with SMTP id 29-20020a170906011d00b007120abf3210mr22444230eje.292.1664947724104; Tue, 04 Oct 2022 22:28:44 -0700 (PDT) In-Reply-To: <86lepvut3l.fsf@gmail.com> Received-SPF: pass client-ip=2a00:1450:4864:20::629; envelope-from=paaguti@gmail.com; helo=mail-ej1-x629.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:296943 Archived-At: --000000000000aa3b1f05ea42d912 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Even more so in the light of lexical binding. I'm trying to introduce people to Emacs and the easier to understand and use as a source of inspiration this manual is, the more probable it is that people actually switch to Emacs. (Or at least this is what I have seen after using it for 7 years as an option in the practical assignments) /PA On Wed, 5 Oct 2022 at 00:22, Tim Cross wrote: > > Phil Sainty writes: > > > On 2022-10-04 21:09, Pedro Andres Aranda Gutierrez wrote: > >> I understood as local variable a 'value that was stored in the > >> function's stack' to be used in the scope of the let. That implied > >> (once again in my understanding) that the global system-time-locale > >> would not be affected and hence format-time-string would not see the > >> change in the value within the let. > > > > Since the addition of lexical binding to Emacs Lisp in Emacs 24.1, > > both results are possible depending on whether you are dealing with > > a dynamic or a lexical variable. > > > > I.e. given: > > > > (defun myfunc () foo) > > (let ((foo 'bar)) (myfunc)) > > > > If foo is a dynamic variable then the let form will return 'bar. > > > > If foo is a lexical variable, then you'd get this error: > > "let: Symbol=E2=80=99s value as variable is void: foo". > > > > Eli quoted the manual: > > > > Local variables created by a =E2=80=98let=E2=80=99 expression reta= in their value > > _only_ within the =E2=80=98let=E2=80=99 expression itself (and within= expressions > called > > within the =E2=80=98let=E2=80=99 expression); the local variables hav= e no effect > outside > > the =E2=80=98let=E2=80=99 expression. > > > > That "(and within expressions called within the =E2=80=98let=E2=80=99 e= xpression)" is > > pretty ambiguous wrt dynamic vs lexical binding, and a few lines later > > it comments very briefly on this: > > > > in Emacs Lisp, the default scoping is dynamic, not lexical. > > (The non-default lexical binding is not discussed in this manual.) > > > > Which keeps the rest of the text accurate, yet in an almost-entirely > > unexplained manner. > > > > I suggest that at this point it has become pretty necessary for lexical > > binding to be discussed in this manual... > > > > * The *scratch* buffer, in which users will perform many if not most of > > their experiments, now uses lexical binding by default. > > > > * If enabled, auto-insert-mode adds lexical-binding: t to new elisp fil= es > > by default. > > > > * IIRC most elisp files in Emacs core are now using lexical binding. > > > > * The emacs-lisp-mode mode-name treats dynamic binding as a warning. > > > > So while it's as true as ever that dynamic binding is the default, the > > fact that so many things nowadays default to *enabling* lexical binding > > really blurs this line, to the point where I think it's unreasonable to > > avoid discussing lexical binding in the introduction to emacs lisp, as > > the user will almost unavoidably be exposed to it. > > > > I think examples would be hugely helpful in explaining the difference > > between the two types of binding. > > > > +1. I think this has become quite important. > --=20 Fragen sind nicht da um beantwortet zu werden, Fragen sind da um gestellt zu werden Georg Kreisler Headaches with a Juju log: unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run a leader-deposed hook here, but we can't yet --000000000000aa3b1f05ea42d912 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Even more so in the light of lexical binding. I'm tryi= ng to introduce people to Emacs and the easier to understand and use as a s= ource of inspiration this manual is, the more probable it is that people ac= tually switch to Emacs. (Or at least this is what I have seen after using i= t for 7 years as an option in the practical assignments)

/PA

On Wed, 5 Oct 2022 at 00:22, Tim Cross <theophilusx@gmail.com> wrote:

Phil Sainty <p= sainty@orcon.net.nz> writes:

> On 2022-10-04 21:09, Pedro Andres Aranda Gutierrez wrote:
>> I understood as local variable a 'value that was stored in the=
>> function's stack' to be used in the scope of the let. That= implied
>> (once again in my understanding) that the global system-time-local= e
>> would not be affected and hence format-time-string would not see t= he
>> change in the value within the let.
>
> Since the addition of lexical binding to Emacs Lisp in Emacs 24.1,
> both results are possible depending on whether you are dealing with > a dynamic or a lexical variable.
>
> I.e. given:
>
>=C2=A0 (defun myfunc () foo)
>=C2=A0 (let ((foo 'bar)) (myfunc))
>
> If foo is a dynamic variable then the let form will return 'bar. >
> If foo is a lexical variable, then you'd get this error:
> "let: Symbol=E2=80=99s value as variable is void: foo".
>
> Eli quoted the manual:
>
>=C2=A0 =C2=A0 =C2=A0 Local variables created by a =E2=80=98let=E2=80=99= expression retain their value
>=C2=A0 =C2=A0_only_ within the =E2=80=98let=E2=80=99 expression itself = (and within expressions called
>=C2=A0 =C2=A0within the =E2=80=98let=E2=80=99 expression); the local va= riables have no effect outside
>=C2=A0 =C2=A0the =E2=80=98let=E2=80=99 expression.
>
> That "(and within expressions called within the =E2=80=98let=E2= =80=99 expression)" is
> pretty ambiguous wrt dynamic vs lexical binding, and a few lines later=
> it comments very briefly on this:
>
>=C2=A0 =C2=A0in Emacs Lisp, the default scoping is dynamic, not lexical= .
>=C2=A0 =C2=A0(The non-default lexical binding is not discussed in this = manual.)
>
> Which keeps the rest of the text accurate, yet in an almost-entirely > unexplained manner.
>
> I suggest that at this point it has become pretty necessary for lexica= l
> binding to be discussed in this manual...
>
> * The *scratch* buffer, in which users will perform many if not most o= f
>=C2=A0 =C2=A0their experiments, now uses lexical binding by default. >
> * If enabled, auto-insert-mode adds lexical-binding: t to new elisp fi= les
>=C2=A0 =C2=A0by default.
>
> * IIRC most elisp files in Emacs core are now using lexical binding. >
> * The emacs-lisp-mode mode-name treats dynamic binding as a warning. >
> So while it's as true as ever that dynamic binding is the default,= the
> fact that so many things nowadays default to *enabling* lexical bindin= g
> really blurs this line, to the point where I think it's unreasonab= le to
> avoid discussing lexical binding in the introduction to emacs lisp, as=
> the user will almost unavoidably be exposed to it.
>
> I think examples would be hugely helpful in explaining the difference<= br> > between the two types of binding.
>

+1. I think this has become quite important.


--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um = gestellt zu werden
Georg Kreisler

Headach= es with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.u= niter.operation we should run a leader-deposed hook here, but we can't = yet

--000000000000aa3b1f05ea42d912--