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 15:08:38 -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> 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="6196"; 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 21:09:26 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 1mpya5-0001Pw-QJ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Nov 2021 21:09:26 +0100 Original-Received: from localhost ([::1]:44226 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mpya4-0006dG-Im for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Nov 2021 15:09:24 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:48178) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mpyZi-0006d7-FP for bug-gnu-emacs@gnu.org; Wed, 24 Nov 2021 15:09:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43522) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mpyZi-00035O-6b for bug-gnu-emacs@gnu.org; Wed, 24 Nov 2021 15:09:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mpyZh-0001mv-UI for bug-gnu-emacs@gnu.org; Wed, 24 Nov 2021 15:09: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 20:09: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.16377845316847 (code B ref 52063); Wed, 24 Nov 2021 20:09:01 +0000 Original-Received: (at 52063) by debbugs.gnu.org; 24 Nov 2021 20:08:51 +0000 Original-Received: from localhost ([127.0.0.1]:55068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mpyZX-0001mN-Ax for submit@debbugs.gnu.org; Wed, 24 Nov 2021 15:08:51 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:65317) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mpyZS-0001ly-V1 for 52063@debbugs.gnu.org; Wed, 24 Nov 2021 15:08:49 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 319BB803D6; Wed, 24 Nov 2021 15:08:41 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 690E2801B5; Wed, 24 Nov 2021 15:08:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1637784519; bh=iXeKBGxfcVsSJz6+HLO3fdc+7iLcEUJ4KWeX9oZy5I0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=ci8jJwl6JO6garPV77orUgxT9x+4otT/r+lr90LjRz0ogFWuxGM7V8wA89yi72asB /qsectSJ3wQtg+zZtb3tOKDykjc3Nr0Nxlo3GCDw6nEJmUAR/rLulAMOQOYP+qpEem a1aoJ/g5w3Yb53WJ2SUjznGaOg8/78XE7Pdpy6XUIGTdV8OQmY+R1l6QRJhnwNoF8U aT2CaJOZElFlnDUYiEDfHoTVCHHRI2mC1icmgm9XTbjQt/InN7gDxO2ySv4y+zFUD7 DimsZ96ZQhT0IGqg6cMF1NhmOh8uIS8EtfIe9PxqBtgdKXALA78d9X9jpFmm+QM1Wx 0M9PSWg1ou9kA== Original-Received: from pastel (unknown [216.154.30.173]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 39765120859; Wed, 24 Nov 2021 15:08:39 -0500 (EST) In-Reply-To: <83v90h72ki.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 24 Nov 2021 21:53:33 +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:220774 Archived-At: >> No, but in 99% of the cases you won't actually *see* a function value >> (unless you specifically go looking for it, e.g. with `symbol-function`). > We also have gobs of variables that are not hooks, which accept > function values. Indeed, tho I think there are a few more such hooks and at least I have looked at hook values a lot more often than I have looked at -function values. > And we also have menu items and mode-line constructs > that sometimes use anonymous functions. I think it's very rare for a user to look at those objects. > And timer functions. I can't remember the last time I looked at such a value. And given the extra info attached to it, it's not very legible so I don't think people are affected very much by a change in the actual function representation there. > And process filter and sentinel functions. Same here: you will often set them, but very rarely will you actually look at their value. > And that's just 5 sec of thinking where one could meet them. Indeed, there are many more places. >> So you'll only get a value of the form (lambda ARGS . BODY) if you use >> the dynamically scoped dialect of ELisp (or if you manually create such >> a list, e.g. with '(lambda ...) or `(lambda ...) or (list 'lambda ...), >> etc...). > > 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... > So why do we emit those warnings for Lisp code evaluated from a file > that doesn't have lexical-binding setting in it? Those warnings predate the introduction of lexical scoping, indeed. They're mostly there so you don't mistakenly write code which the byte-compiler can't compile (and which `flymake` can't analyze to give you further feedback about issues in that code). It's all about the difference between code and data ;-) Stefan