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: Thu, 6 Oct 2022 11:00:45 +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="00000000000057cebc05ea59effc" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23813"; 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 Thu Oct 06 12:23:04 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 1ogO1w-0005xf-NA for ged-emacs-devel@m.gmane-mx.org; Thu, 06 Oct 2022 12:23:04 +0200 Original-Received: from localhost ([::1]:33760 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ogO1v-0000Ju-4Q for ged-emacs-devel@m.gmane-mx.org; Thu, 06 Oct 2022 06:23:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56642) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogMks-0006V5-2n for emacs-devel@gnu.org; Thu, 06 Oct 2022 05:01:25 -0400 Original-Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]:37887) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ogMkk-0001ZK-Cq; Thu, 06 Oct 2022 05:01:18 -0400 Original-Received: by mail-ed1-x533.google.com with SMTP id w10so1854354edd.4; Thu, 06 Oct 2022 02:01:13 -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=19x7hRbSceCngsyV9UpiGJ0VNt5CI25gnrk+zOg/dvs=; b=GIV1f5bc0kFRhUAihnVKf0Sc1WlFlEudmcZ7gHMNfAJ1tAxhymsJeNlt5PWVA5iM7C SvJtirQjf+fzqqx9tcb+Yv10/1hLGJ3cyKucDc0VPX9mD6vwOxnhzy62E33A+DUZtnY9 xjh8KZMmG1xJjMC5fYbPouxOnb/VdCq5v84l1JxqGjQ9pWYZAS1Glpz7zFp073tfE0VX YZeK1duHdO/xWH8wGixyM6VqfA8PFjMAAH19KMPvRatvyJyenV1XqIopUvT9wER+QoUR d1YNq9WIOglSi1MAKHFx0clEtFyaLcdC0uxoogDd9pfm11sTEKiMaiHodOzAZU6fsBQn P4FA== 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=19x7hRbSceCngsyV9UpiGJ0VNt5CI25gnrk+zOg/dvs=; b=fG884GQAqLSAQWHNgO7nLEEq0R5u//O5v3iIko8ahfe1lg5cWQcrWg2EauVD19/RR/ BNo63jYtb3dokjHlDuo+JvXtXIpbaAVbltuIJw/RBdVl4QrZXLd0I2MlKfb0QcVyueVX 03JpJoib3eHQwGoSXgq2jPniG0uRL1VnOsADYDOUJyrYT1wwoRxeiea4VTReTTj3ieEM nxZ6ATikF8Wk5SIgpg8z1dvZ+fPxasDiFjIbg+9hjTrTJbXTTeRVv+knTYrYGxz3VFSp 8J/3tt73UVFCbNhn1ypDvO+Gm0igQ7c+73ASEjvf0Pit1/sMc37BPeCtjw7S1sNMjtsX 7xtg== X-Gm-Message-State: ACrzQf3MqfR8RHZdrH6P9Nz/6mQC84F9/RxdDlGuL/C2J1fHqoQR2h+r vzoZLcUENzyKCavpsYBqZlGowvV1Imlizp12T60= X-Google-Smtp-Source: AMsMyM5ExW9b+m+F9QG6iuICSop9KntB5IX0cRpFXsl78FKtcpdlbY4t3Di1CFFNqhH0S1kRCxCkhV4LurpFVEXN+QM= X-Received: by 2002:a05:6402:3904:b0:451:f01c:9217 with SMTP id fe4-20020a056402390400b00451f01c9217mr3551834edb.78.1665046872049; Thu, 06 Oct 2022 02:01:12 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::533; envelope-from=paaguti@gmail.com; helo=mail-ed1-x533.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:297084 Archived-At: --00000000000057cebc05ea59effc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So, can someone more informed than myself provide an informed patch Thanks, /PA On Wed, 5 Oct 2022 at 07:28, Pedro Andres Aranda Gutierrez < paaguti@gmail.com> wrote: > 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 ret= ain their value >> > _only_ within the =E2=80=98let=E2=80=99 expression itself (and withi= n expressions >> called >> > within the =E2=80=98let=E2=80=99 expression); the local variables ha= ve no effect >> outside >> > the =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: >> > >> > 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 lexica= l >> > binding to be discussed in this manual... >> > >> > * The *scratch* buffer, in which users will perform many if not most o= f >> > their experiments, now uses lexical binding by default. >> > >> > * If enabled, auto-insert-mode adds lexical-binding: t to new elisp >> files >> > 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 bindin= g >> > really blurs this line, to the point where I think it's unreasonable t= o >> > 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. >> > > > -- > 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 ru= n > a leader-deposed hook here, but we can't yet > > --=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 --00000000000057cebc05ea59effc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, can someone more informed than myself provide an infor= med patch

Thanks, /PA

On Wed, 5 Oct 2022 at 07:28, = Pedro Andres Aranda Gutierrez <paag= uti@gmail.com> wrote:
Even more so in the light of lexical binding.= I'm trying to introduce people to Emacs and the easier to understand a= nd use as a source of inspiration this manual is, the more probable it is t= hat 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)
<= br>
/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 b= eantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
<= div>unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should = run a leader-deposed hook here, but we can't yet



--
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

--00000000000057cebc05ea59effc--