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: Mon, 29 Jan 2024 10:41:37 -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="30967"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 29 16:42:27 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 1rUTmF-0007rR-CI for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Jan 2024 16:42:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rUTlY-00070B-KC; Mon, 29 Jan 2024 10:41:44 -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 1rUTlW-0006zk-Ua for emacs-devel@gnu.org; Mon, 29 Jan 2024 10:41:42 -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 1rUTlV-000425-6B; Mon, 29 Jan 2024 10:41:42 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 97880100115; Mon, 29 Jan 2024 10:41:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706542898; bh=wO1G5WzPbUFzvX5LLcSjoq6YXQqpqFMOGC6pHh0wXig=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=WAHkdVQzTqsiSnIwNe9QXTw1dLr4GObz+CA+YFG5bgYbiD22/c4MF8P5+LiFeyU3S ZU5DbSAnph6T0Jy8nRpfsT5LNOgVRXosEoj0CM8Pj+okZGbt8qDhBronoTOqWBQpI7 aAcBGLh9Wpv1s1JcZMpwBNaRlg5gbBlxkAtymRz8BlpQCNLmAh5cKEaf7PCHXaqjRC Ul1l7daV1OyjhpUJU7zQwGEwMuIspIz5+sAUeWkjFt0iOU45bChbC7PtR4pLNQOX36 0zdbd8k8ZJUkArN+FYkN4gyAQt+YDi4DevnV/wx8wFdF4h8WrJzu+xsF0bCyd8UrcP UjO20CZneVHxg== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3173110004C; Mon, 29 Jan 2024 10:41:38 -0500 (EST) Original-Received: from pastel (unknown [45.72.206.68]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0C82C120D21; Mon, 29 Jan 2024 10:41:38 -0500 (EST) In-Reply-To: <864jew40m3.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 29 Jan 2024 17:31:48 +0200") 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:315593 Archived-At: > And the reason(s) you are "annoyed at the use of lists to represent > function values" are?... IOW, what will we gain by using your changes > in this matter? Beside taste and philosophical differences, the main motivation is to make `consp` and `functionp` mutually exclusive so as to eliminate the risk that a list be considered mistakenly as a function or vice versa. I mentioned that this risk of confusion is the reason why our completion functions do not officially support completion tables represented as lists of symbols (even though in practice they work fine (except when the first symbol happens to be `lambda` or `closure`)). It also occurs in various other places where we want to allow either a function or a list. E.g. a recent bugfix in YASnippet: commit 9228fd983bb9e71d44d406433a46495b22640801 Author: Marten Lienen Date: Mon Jan 22 11:08:44 2024 +0100 * yasnippel.el (yas-buffer-local-condition): Check functionp before consp to allow closures - Stefan