From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.help Subject: Re: Closures - do you understand them well? Date: Sat, 28 Jan 2023 01:44:11 +0100 Message-ID: <875ycrsd2c.fsf@web.de> References: <87h6y5pt8k.fsf@web.de> <87bkodpqnk.fsf@web.de> <87k030tlfh.fsf@web.de> <87ilike1l8.fsf@gnu.org> <87cz8suv92.fsf@dataswamp.org> <87pmcpo1wz.fsf@web.de> <87pmcpm9vn.fsf@web.de> <87sfg8xcps.fsf@dataswamp.org> <87h6wmacdn.fsf@web.de> <87v8krlo9q.fsf@dataswamp.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3858"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:2QwoA+BJDhEujtwFuEMai8mNN2Q= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 28 01:45:04 2023 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 1pLZL5-0000ok-JR for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 28 Jan 2023 01:45:03 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pLZKV-0006je-Pn; Fri, 27 Jan 2023 19:44:27 -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 1pLZKU-0006jT-2B for help-gnu-emacs@gnu.org; Fri, 27 Jan 2023 19:44:26 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pLZKP-0001lP-2W for help-gnu-emacs@gnu.org; Fri, 27 Jan 2023 19:44:25 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pLZKM-000Aae-OI for help-gnu-emacs@gnu.org; Sat, 28 Jan 2023 01:44:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.15, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 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-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:142544 Archived-At: Emanuel Berg writes: > Michael Heerdegen wrote: > > > The (unevaluated) expressions are just lists. As values they > > are "quoted lambdas" with all of the problems they come > > with. The Elisp interpreter still accepts them as > > function values. > > Okay, why, for technical reasons? Is your question why they are (still) accepted? I'm not an expert, but I'll try to give an answer. In the dynamical binding dialect, lambda expressions were self-evaluating expressions: the function value was identical (`equal') to the evaluated expression (when interpreting uncompiled code). See the definition of `lambda' in subr.el. That fact could be exploited to build function values with certain properties in a copy-and-paste like style (using backquote expressions, typically). "Poor-mans closures" already had been mentioned. Old code still uses such techniques so I guess it would break too much of such stuff if such values would not be supported any more. Oh, and of course, since the Emacs interpreter has to support both dialects at the same time (you can use packages with lexical binding enabled and disabled in one and the same session), the interpreter has to support such values anyway since they are valid in one dialect. AFAIU, conceptually the type of binding is a property of the code - the interpreter just can run both types of code. > And what values are the correct function values then? Lexical closures use a different representation - see (info "(elisp) Closures") The actual structure is not interesting for programming any more. And in compiled code or natively compiled code function values are not such nicely explorable lists anyway. Michael.