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: Sat, 27 Jan 2024 09:25:10 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6811"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 27 15:26:19 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 1rTjdT-0001Yk-Kr for ged-emacs-devel@m.gmane-mx.org; Sat, 27 Jan 2024 15:26:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rTjcg-0003ji-7F; Sat, 27 Jan 2024 09:25:31 -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 1rTjcU-0003j9-Cv for emacs-devel@gnu.org; Sat, 27 Jan 2024 09:25:19 -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 1rTjcR-0007li-He for emacs-devel@gnu.org; Sat, 27 Jan 2024 09:25:17 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2B2C9100068; Sat, 27 Jan 2024 09:25:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706365511; bh=3mtqXLnl4YxxHZPanBBDItUv35e91AIwioafUiZrIh4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=daVX9pjkCOhBu3xeQi0sXUoiPAv6NYBlEckBEGwdlKhdXlEKFXJ60okjSeQ8U3FfW sRfkcaIc+LhY8Jjw/ghEF9QVEHE6Leot8JVORoTv8uHtQckhwo+FC9hUhgZVhWDu1s IeB13Vqeg3g2+qBllgLSVNvZmIE92cvt+UnIh/nSEYwqI+eQ+X46tfFXcxa/kaCRCa cW+gC4SOUjpNczCbWf7DABgOL2EHAJWPOy8YdhxqYZIuiSWE32HAbykafbajGQUSwp ugy6T+qHiT+VkdAk3MZYE91oqtwUICgdo3SfMlsHVeuL2YhXumfLIqF1Vp20kUfRls 1Hdpg4CBBlN3A== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BC44D10004C; Sat, 27 Jan 2024 09:25:11 -0500 (EST) Original-Received: from pastel (unknown [45.72.206.68]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8C161120483; Sat, 27 Jan 2024 09:25:11 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Sat, 27 Jan 2024 11:00:17 +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:315485 Archived-At: >> I've been annoyed at the use of lists to represent function values for >> a while now. > Why? Lists are the natural representation, and traditional in Lisp. > They bring all sorts of advantages (like being able to manipulate code > easily in Lisp). Not sure how that relates. When the code is byte-compiled we already can't access the function as a plain list. And when it's native compiled, we literally can't access its internals from Lisp. at all. > Blunder? Having (closure ...) alongside (lambda ...) is an > inconvenience, yes, but ... Why a "blunder"? Because we could have easily used #[closure ...] instead and the problem would be mostly solved by now :-) > Please don't do that. If you must invent a new form, then invent a new > symbol to signify it. Misusing #[...] will lead to problems and extra > work for everybody (as, for example, using the doc string field in > oclosures for something else has led to extra work). Actually, if you look at the patch, you'll see that the change tends to reduces the amount of work that's needed elsewhere because docstrings and interactive-forms are now found at the same place for interpreted and (byte-)compiled functions. > Any packages out there that deal with the internal format of Lisp code > will be severely affected. Don't know about "severely", but yes they may be affected. There really aren't vry many of them, tho. > For example, my amendments for bug #67455 (Putting position information > into doc strings) are already difficult enough. I'll gladly take care of making the necessary adjustements. > This change would add a whole new layer of indirection into bug > #67455's changes. I don't see how/why. In the worst case, it will replace one special case with another. Stefan