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: Fri, 26 Jan 2024 16:13:14 -0500 Message-ID: References: <86msssble8.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="23968"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 26 22:14:00 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 1rTTWR-00061v-Nb for ged-emacs-devel@m.gmane-mx.org; Fri, 26 Jan 2024 22:13:59 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rTTVr-0000CV-I7; Fri, 26 Jan 2024 16:13:23 -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 1rTTVp-0000CK-US for emacs-devel@gnu.org; Fri, 26 Jan 2024 16:13:21 -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 1rTTVo-0007SP-8n; Fri, 26 Jan 2024 16:13:21 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7BFD8444709; Fri, 26 Jan 2024 16:13:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706303596; bh=VGwSx/yw1zmcoiYVRVhcUWh4Ny+W4zBKX+HGwXhq7YU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=AAPeln5cHDmwreuonJzhhuBi+g28Vbhe9rIogElni7b12gK9cUbsf8zbacRYbI+Oe sERef2n5trkwo987KTeTJwBQUw/MdUtpnGktspHNlDG5MfZDfXhvlrhiFlGBFAhnB7 Fk8Zkxs2V8b+esRVBOalCZAYyO10VfiMHey7jdrP+sIoPPM2zVvJNe2zUSPAhQS6Qj HayerJADpleZiusvUvYvA5aD1NfkXPdOj16N8KkLHXMEdl0y4Ph3jjwN+pBjGzRjaP XgHe6rXy6mGp9bnphgdJSkTUkhNZXPTChfLnM6SlhG+enuz/wC3MaJuHr1BZuR7Rs/ BJlZIw5XnbUQg== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 386F5444707; Fri, 26 Jan 2024 16:13:16 -0500 (EST) Original-Received: from pastel (unknown [45.72.206.68]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0F7BE120616; Fri, 26 Jan 2024 16:13:16 -0500 (EST) In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Fri, 26 Jan 2024 19:22:56 +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:315439 Archived-At: > Is fine and correct, but: > > (funcall '(lambda ())) > > Shouldn't be fine, yet it is. That is related but I'm not really interested in disallowing it. Rather I'm annoyed at the corner cases where (functionp (mapcar ...)) can occasionally return t, simply because the returned list happens to start with the symbol `closure` or `lambda`. This is one of the motivations why completion tables are defined to allow "lists of strings" or "alists whose keys can be strings or symbols" but not "lists of symbols": even though in practice lists of symbols work fine 99.9% of the time, they are not reliable because they'd be confused with a function when the first symbol happens to be `lambda` or `closure`. There are various other circumstances where we like to accept either a function or a list of things, but where the test is not reliable and can give different results depending on whether the code is compiled. Stefan