From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: Understanding the "let" construct and the setting of variables Date: Thu, 17 Dec 2020 08:55:52 -0800 (PST) Message-ID: <3b1a7936-913a-4736-9b12-0d3e04333c74@default> References: <87zh2d1byp.fsf@fastmail.fm> <87tusk2754.fsf@fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23268"; mail-complaints-to="usenet@ciao.gmane.io" Cc: help-gnu-emacs@gnu.org To: Joost Kremers , steve-humphreys@gmx.com Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 17 18:01:16 2020 Return-path: Envelope-to: geh-help-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 1kpweR-0005wh-Tq for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 17 Dec 2020 18:01:15 +0100 Original-Received: from localhost ([::1]:49610 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kpweP-0004ys-7z for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 17 Dec 2020 12:01:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33876) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kpwZT-0002x2-Rr for help-gnu-emacs@gnu.org; Thu, 17 Dec 2020 11:56:07 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:36458) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kpwZP-0002vK-3a for help-gnu-emacs@gnu.org; Thu, 17 Dec 2020 11:56:07 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BHGocBC065434; Thu, 17 Dec 2020 16:55:55 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=/k0BuMHFB70635YJgB6JIJXNy05pc1eagKD0PYL4q7A=; b=Pl1shD9qk8HX2gz5uuJDfuANA9qH6c00zwvJ3VwNTnzUodlDvzE4YV5V4iJbJ3pop3L2 m/sqSeKy6DTan6Hgk53JPBwP9ZiUTde02f3wbB15S0F0laJ56Lo++cSuU4qx9M5M7kld i8BFiyjPWbVtTRUkTaivxI09lmuS5kGnFjXLGta6sGzpRAn5xamAGfUD//mu3D73OhZi 7Ui26emMi68sZ0r5ZQhsYn5mVz9v98mYl2dt1Tp0XVhUYQXXYZiuG8ogw5R7RnjGuZ0C HGRMtoriOsRvZenz2a4HsSPL2/+fX6sk3DRhiAUkAIBIQZ+/svEBYDG/CLm/vhiHq+7p gQ== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 35cn9rpe6b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 17 Dec 2020 16:55:55 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BHGpJsu004841; Thu, 17 Dec 2020 16:55:54 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 35g3revr9d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Dec 2020 16:55:54 +0000 Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 0BHGtrH9032219; Thu, 17 Dec 2020 16:55:53 GMT In-Reply-To: <87tusk2754.fsf@fastmail.fm> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5071.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9838 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 malwarescore=0 spamscore=0 suspectscore=0 mlxscore=0 mlxlogscore=897 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012170116 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9838 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxlogscore=994 impostorscore=0 lowpriorityscore=0 clxscore=1015 spamscore=0 malwarescore=0 priorityscore=1501 phishscore=0 mlxscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012170116 Received-SPF: pass client-ip=156.151.31.86; envelope-from=drew.adams@oracle.com; helo=userp2130.oracle.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:126466 Archived-At: > Yes, indeed. Variables bound with `let` or `let*` only exist inside the > `let`. > So as soon as you put the closing parenthesis matching the opening > parenthesis > directly before the `let`, the variables go out of scope and no longer ex= ist. > (There are actually a couple of subtleties involved that make this statem= ent > less than universally true, but those issues shouldn't concern a beginner= .) This is not true of dynamically scoped, i.e. "special" vars. What is correct to say is that the let _binding_ of the variable no longer exists, not that the variable itself no longer exists. In the case of a dynamic variable, it continues to exist. And its binding from the let continues to exist as long as the code in the let body is executing. [Yes, some people will consider a let binding to create a _new_ variable. In that sense you can say that that var ceases to exist. But IMO that isn't as clear to users as it is to distinguish the binding from the var. And even if you use the words that way, you still need to point out that the var continues to exist as long as the code within the let body is executing (when the binding is for a dynamic var).] The best explanation of let binding in Elisp is in the Common Lisp doc, IMO. In particular, CLTL2's explanation of dynamic and lexical binding is quite clear. It applies equally to Elisp. https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node43.html