From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#52063: 28.0.60; Confusing presentation of lambda Date: Wed, 24 Nov 2021 17:02:12 -0500 Message-ID: References: <83czmqaegb.fsf@gnu.org> <874k82vwe5.fsf@gnus.org> <831r35afde.fsf@gnu.org> <87v90hu36b.fsf@gnus.org> <83v90h8zjw.fsf@gnu.org> <87r1b5u1cl.fsf@gnus.org> <83pmqp8vps.fsf@gnu.org> <87sfvly160.fsf@gnus.org> <83ilwh8pf2.fsf@gnu.org> <83a6ht8n3p.fsf@gnu.org> <83v90h72ki.fsf@gnu.org> <83r1b571mc.fsf@gnu.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38871"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: larsi@gnus.org, 52063@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 24 23:03:14 2021 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 1mq0MD-0009rL-PC for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Nov 2021 23:03:13 +0100 Original-Received: from localhost ([::1]:36444 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mq0MC-0003g5-1M for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Nov 2021 17:03:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:46024) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mq0M2-0003c4-2G for bug-gnu-emacs@gnu.org; Wed, 24 Nov 2021 17:03:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43588) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mq0M1-0006yI-QB for bug-gnu-emacs@gnu.org; Wed, 24 Nov 2021 17:03:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mq0M1-0004jL-LD for bug-gnu-emacs@gnu.org; Wed, 24 Nov 2021 17:03:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Nov 2021 22:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52063 X-GNU-PR-Package: emacs Original-Received: via spool by 52063-submit@debbugs.gnu.org id=B52063.163779134418138 (code B ref 52063); Wed, 24 Nov 2021 22:03:01 +0000 Original-Received: (at 52063) by debbugs.gnu.org; 24 Nov 2021 22:02:24 +0000 Original-Received: from localhost ([127.0.0.1]:55134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mq0LQ-0004iU-9v for submit@debbugs.gnu.org; Wed, 24 Nov 2021 17:02:24 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55417) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mq0LN-0004iC-0L for 52063@debbugs.gnu.org; Wed, 24 Nov 2021 17:02:22 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 10FC1805CC; Wed, 24 Nov 2021 17:02:15 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3DE5A803D6; Wed, 24 Nov 2021 17:02:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1637791333; bh=xYaacAd42lyPTvgOfiGWbQbPFCQc2iNVgSzOvOYYXR0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=mSEUseoQFt73vqUaizUGdU+KboSBchnbefW/AYbqTYngEgULWxb1V8W8bPlPDksRB i4YqZCjZE6+FpjHP215K+wkJXv+yw/apSmuu1fIwPb7Th0LXluXn4lqnpXqQk8VpuH S6hkLfoGx56SEfWi1f3+Tknrew8vqvhaQEH0/8c1EeSFh67BjWjWZn75ZISrVHV6zg I3OdYAXOU0G+g43nLKoHCEtqBVXrWqxxhmKeX1eRq5zvf23mmhBKVNtHcA9cc9Ay4R ugnuc3CUupoxaye2k+EY7mboipZb9bKVmxkK99MEcVTZJGQG+BDSJ9GLo6601c9Q83 nWoI6xjutLeNQ== Original-Received: from pastel (unknown [216.154.30.173]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0E62F120473; Wed, 24 Nov 2021 17:02:13 -0500 (EST) In-Reply-To: <83r1b571mc.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 24 Nov 2021 22:14:03 +0200") 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" Xref: news.gmane.io gmane.emacs.bugs:220781 Archived-At: >> > So I guess the warning about quoting lambdas with ' instead of #' is >> > actually misleading people into getting these closures instead of the >> > lambdas they might expect? >> >> A value (lambda ...) is fundamentally a list. The rest of the system >> (e.g. the byte-compiler, flymake, ...) can't know if you intend to use >> this list as a function, so it can't really look inside to compile its >> body, warn you about typos in its body, or uses of obsolete >> vars/functions, etc... > > I'm talking about evaluation, not about byte-compilation. > This happened when Emacs was processing my init file. I'm tlking neither specifically about evaluation nor compilation, I'm just talking about the meaning of '(lambda ...) which prevents our tools from looking at the code inside of it because those tools can't tell whether it's supposed to contain source code or just arbitrary data. >> It's all about the difference between code and data ;-) > What difference? I always thought that in Emacs Lisp there's no such > difference. I think saying that "code is data" is misunderstood. All it means is that code is exposed as a kind of data, e.g. via macros. But obviously not every piece of data is a valid and usable piece of code. And when ELisp knows that a specific piece of data is actually a piece of code, it can take the liberty to manipulate it accordingly under the assumption that it's "somewhat opaque" and that the only thing we're going to do with it is evaluate/run it rather than manipulate it with, say, `car/cdr`. E.g. when we load a .el file containing: (defun foo (xs) (dolist (x xs) (when x (message "%s" x)))) the `symbol-function` cell of `foo` will not contain (dolist (x xs) (when x (message "%s" x))) > Does lexical-binding change that as well? It makes the difference a bit bigger. Stefan