From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Distinguishing `consp` and `functionp` Date: Tue, 30 Jan 2024 19:22:42 -0500 Message-ID: References: <86msssble8.fsf@gnu.org> <86bk9448ai.fsf@gnu.org> <864jew40m3.fsf@gnu.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="4243"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 31 01:23:42 2024 Return-path: Envelope-to: ged-emacs-devel@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 1rUyOA-0000kz-7a for ged-emacs-devel@m.gmane-mx.org; Wed, 31 Jan 2024 01:23:38 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rUyNO-0001Vx-Fw; Tue, 30 Jan 2024 19:22:50 -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 1rUyNM-0001Vl-Df for emacs-devel@gnu.org; Tue, 30 Jan 2024 19:22:48 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rUyNK-00033z-OD for emacs-devel@gnu.org; Tue, 30 Jan 2024 19:22:48 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C71C1442A76; Tue, 30 Jan 2024 19:22:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706660563; bh=UmbumTt8g0kdjGg/fdIJC0TXMg71/h8HVojRgJe2Lsw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OG1GxC8UEY+Ajfs8tpEbEl+YJTmlZ/CgC7C9eZVNI1ij+6Zka7tO8yM+Ionxx5Wju SwAkplipqAOjhjUyCPVFyHikrz5gTzvTYdLRzujUjZqb6VclBhiX97sn9W0NtW75gw 8omJ1UjX6tl5ENJrotK9UWoTd+TrxWX91DNY6USq31EWdd8ouUtSqhdjEVqQLmC8H4 y8fF/ESiyF3mHXiLg5dgabmvNgwgtFmvdBG67ACK3JDzf+tMWKEYWwtycZMIgN7mh0 G6P0iXByvTiojPM9Z62IMBu2jwzQkls291MIfFC2Elj4qJAEcG79Hy/HuyOP9tzUH8 6qpqEbqjrCO+w== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3F89B442A58; Tue, 30 Jan 2024 19:22:43 -0500 (EST) Original-Received: from alfajor (104-222-119-131.cpe.teksavvy.com [104.222.119.131]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 12E6612046C; Tue, 30 Jan 2024 19:22:43 -0500 (EST) In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Tue, 30 Jan 2024 23:43:38 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:315647 Archived-At: > It sure seems to suggest many many others do the same: start by > calling functionp. Indeed, the current representation of interpreted functions tends to encourage it. > Won't they _all_ be broken if users have been > putting lists in those user vars by mistake? Could be. That's one of the reasons why my patch doesn't change `functionp` (yet). > One thing it'd be nice to have for runtime warnings is some kind of > file location hint. Alan has plans to work on that, tho I strongly suspect that it won't help for this problem: the functions for which we need this info are the functions which Emacs thought were lists, so Alan's plan to try and keep some source info along with function wouldn't help here (unless we keep source info for cons cells, which I guess could be a possibility: it would be expensive to do for all cons cells read from files, but if we limit it to cons cells whose `car` is `lambda` is might even be doable). > Maybe check the calling frame? I suspect that most cases will look like your Eglot example, where by the time you get to the `funcall/functionp` the backtrace doesn't immediately tell you where that function comes from (it can still be helpful info to trace it back, but it may require digging into someone else's code). > Dunno. SBCL's compiler is pretty good, it propagates types and warns > say, when using generic+ instead of must faster fixum+. Knowing "this is a function" isn't terribly better than "this is either a function or a cons cell starting with `lambda`": it will rarely let you turn a generic+ into a fixnum+. Stefan