From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#66756: 30.0.50; [PATCH] Improve discussion of 'let' in Elisp Introduction manual Date: Sun, 19 Nov 2023 09:38:54 +0100 Message-ID: <878r6ut9wh.fsf@gmx.de> References: <3ade119d-0f0d-e60e-1bdc-9c7e02c1559c@gmail.com> <381836df-c16f-b3e7-d0c4-473290e165de@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7915"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: eliz@gnu.org, rms@gnu.org, 66756@debbugs.gnu.org To: Jim Porter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 19 09:40:24 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 1r4dLr-0001r2-Qv for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 19 Nov 2023 09:40:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r4dLd-0003B7-NY; Sun, 19 Nov 2023 03:40:09 -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 1r4dLW-0003Aa-2a for bug-gnu-emacs@gnu.org; Sun, 19 Nov 2023 03:40:02 -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 1r4dLU-0005tv-SI for bug-gnu-emacs@gnu.org; Sun, 19 Nov 2023 03:40:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r4dLV-0003lS-SH for bug-gnu-emacs@gnu.org; Sun, 19 Nov 2023 03:40:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Nov 2023 08:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66756 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 66756-submit@debbugs.gnu.org id=B66756.170038314814398 (code B ref 66756); Sun, 19 Nov 2023 08:40:01 +0000 Original-Received: (at 66756) by debbugs.gnu.org; 19 Nov 2023 08:39:08 +0000 Original-Received: from localhost ([127.0.0.1]:49866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4dKd-0003k9-Mr for submit@debbugs.gnu.org; Sun, 19 Nov 2023 03:39:08 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:58717) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r4dKa-0003jc-0S for 66756@debbugs.gnu.org; Sun, 19 Nov 2023 03:39:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1700383135; x=1700987935; i=michael.albinus@gmx.de; bh=M1I9TVLt4uo0h6wZWL9eUyhuT+vbc07nid2TNIFsVjM=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References: Date; b=B7Rw707J4eWlABIAHZBmnEt1aNhPfnzFgNgd52uFDj6IEtqyQFyq3s0IfPhmzIQN iZmP8NGOjzTNQjs2jmIh1Ce3SfQLsXyWguQUmT9zg9WCQRlOzIPYmoLwVESSqVQgJ jRmTmXyOcQGy5jRGH9qvDi7xJIo1wmZkpzTRUzjCE4QUs2T7CbW9u+vrv86wE7/OR eB4eWpBk5OQbJcKSTbdizJW8I0nOAID6i/B+n4TDLwkgJIhWOKeMOZm2jlcqxTmjV U9mMnrYnL+Gp7ZQdoi59ZJrThfA7O/JvD0bFF7dQu45mQuwBG+HNwn/M78Fl0S7aM UXtOLsKTJCt/gLnlGw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from gandalf.gmx.de ([185.89.39.30]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N0XCw-1rIkOZ2zSe-00wRM1; Sun, 19 Nov 2023 09:38:55 +0100 In-Reply-To: (Jim Porter's message of "Sat, 18 Nov 2023 21:30:11 -0800") X-Provags-ID: V03:K1:uWEMuC+jODN6xmCCNm62YTFri9lGa87RFxls2iKwytFY4U2hPRl IL5eFS0OMB7pc8bto/9lN+cEIdwGa+dhSL0/x3v+b0O+STkYO1juHPuOykZ/25kRdQ9s0w1 Xjpkwm63xFtY9MvNfZIzQ4fFzl7YgIr7zE6Ep2N4kXcaMTd+Bc3wMXCkljG8DFrRZixE5h3 28/SRnCGeJ44SlOmbe9UQ== UI-OutboundReport: notjunk:1;M01:P0:gukPw5BsXJQ=;w6T5vzV4QOl3dIDYxYOn7n0WMXa vkOo57PXnUP+oZIipaEp2GqLWl5Jpd/VZiFM8dqQ92zhg80FQ8NMXJDOHMOVeDuYzLhCjrUgG jpsptA+w4LoajeVQNcZVAvrN8Z1rRPUG+Z7XrILc8+5LrkbJMm1oH7kNw6NkqUBZXA/zNqSox PMekpCrqm7tNgjDkB4CCj/8L8yaDwgLf+GAI77U29kxDTOKMQ6lrCyafbyZkvVwt9Rl7zNI/n /66yDUlog5q/5wpT5Gk2mcVZeeHJ2i7YhOGuwp6jAl352n9O/fLu+u5X7tM86zuMStXX5SFYi jXWNcIpG81m3WnDmhnf+GmmpkCZ9uhS90ieASoaV0pRHAHnQq/2EVG2v9ZxFBaSmsPsK9LeUh KuV352LIcOR4tovEc64SzpFdubF/AfwiwpDK8XnLkDHcet/pKluPpCC1q9fzMs9dKuVWxxSYY RBz+IqURAgX9xM1vYR5UIZLvIy5ubm3PMlI8dkOqYOtVxAAYc79iVFI09a3NbqRqhmGWLDK/l 0ByT7K4SJlZrwm0lLOl1iXbEvTT0nhIog/bld6BxN+db2s1I6EpJfp/6Qs4Xm06wcAkGC9NXs ZwTWHHKc122SfwYJtXJNcxcVhT63LjaQrc5Qv2AAbDMdyT6j1UNdpDLMVeiUc5yHW2sHKGqOR SfFzPO7CZh4TIJhiydnVgqs1loCrzShTtKGJueMnllwBYfInuMUHZyWw1eNe6kuuyQDO08rAW zXyS+G7Zj2yFBbzSvRoZsoGhPWotfSmSZm65g0ceS0Sojo84Gepf9xnhyFqzq75xhd+fbnKx 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:274599 Archived-At: Jim Porter writes: Hi Jim, > +In some cases, both lexical and dynamic binding behave identically. > +However, in other cases, they can change the meaning of your program. > +For example, under lexical binding, if you call a function inside of a > +@code{let} body, that function's body would be unable to ``see'' (or > +modify) the value of a local variable from the @code{let} expression: > + > +@example > +;;; -*- lexical-binding: t -*- > + > +(setq x 1) > + > +(defun getx () > + x) > + > +(let ((x 2)) > + (getx)) > + @result{} 1 > +@end example > + > +@noindent > +If we use dynamic binding instead, the behavior is different: > + > +@example > +;;; -*- lexical-binding: nil -*- > + > +(setq x 1) > + > +(defun getx () > + x) > + > +(let ((x 2)) > + (getx)) > + @result{} 2 > +@end example > + > +Now, the result of @samp{(getx)} is @samp{2}! That's because under > +dynamic binding, when @code{getx} looks for the value of @code{x}, it > +sees the value we set in our @code{let} expression. In other words, > +the call to @code{getx} happens during the @emph{time} when our > +@code{let} expression is active. Under lexical binding, @code{getx} > +doesn't see the value from our @code{let} expression. That's because > +it happens in a different @emph{place} than the @code{let} body. Would it be worth to emphasize, that a declaration of x changes this? That is, when a variable is declared, both lexical and dynamic binding behave identically. @example ;;; -*- lexical-binding: t -*- (devfar x 1) (defun getx () x) (let ((x 2)) (getx)) @result{} 2 @end example Best regards, Michael.