From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.devel Subject: Re: Declaring Lisp function types Date: Thu, 29 Feb 2024 00:10:15 -0600 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22498"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: acm@muc.de, acorallo@gnu.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 29 07:11:31 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 1rfZdj-0005f8-02 for ged-emacs-devel@m.gmane-mx.org; Thu, 29 Feb 2024 07:11:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rfZcf-0007Zo-A3; Thu, 29 Feb 2024 01:10:25 -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 1rfZcd-0007ZX-Vi for emacs-devel@gnu.org; Thu, 29 Feb 2024 01:10:24 -0500 Original-Received: from cyan.elm.relay.mailchannels.net ([23.83.212.47]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rfZcc-0003lo-75; Thu, 29 Feb 2024 01:10:23 -0500 X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 043516C1F9E; Thu, 29 Feb 2024 06:10:18 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a300.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 897F76C1C1B; Thu, 29 Feb 2024 06:10:17 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1709187017; a=rsa-sha256; cv=none; b=uG6SeamwHAOd6lesgSWE9KIyLmM8zLPWspdd/LUnGUIbJ8at6pJOV1DcA4EWhZvHU2Ke49 abKjW6FwbxiH3BF0O8xyQNlMgBBoupPXEM0WERSPBg1OvKY0xbN3wtMUjAf5onZvaTQNg/ 2pcI2AduwU064Q2C3QrWNupyiBD75VqI7KMSPwG5XR7cnHu+o+WfFV2aM0Z1wm709f3Sxn 64g3EVc+zmm4lWSdESFdOJuxgDWjRZYqBoiLwFchlJkNsbhXy+mqO1p0hd1e78jENJhrjd cqGQtogtvmInC/W6Mnhc1irTT89cQ7e3sNpgPK1RVPuCNf9PvFU5U99CLs3iCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1709187017; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4pOr1wWb2ZfYRhPPQfqv/GKixFVzc02iGB2ZEWlOZgI=; b=hHYNzRVXstq7Xmv9df3rrqsv6lvzkln7edIvqLEIFWQYBgKcCrxlB2MsDZwZzXUaGXy9O2 34hnzo3ioHaBwcA5OQq0wdw2mVbd3T8Fnp09m5knUKaOqK8Rw6z06UhAbxPAqsvg3VtiSm b42lQNfqIdN+X8WHQ2asfDemf0sNJ4PuaUZQg+qJiv9vAywaS1tcd+87onuxozz1D/aXuS RMkCS4mk38nbNzGcdrc+JjKgaJvRtl2Qw7dVlE8by8M/2c1Pu4vAhB2abOh7uyyPjFkVAJ JzteZyHR49DGuCFIeFvCuiwc7q6luSRwNC1ZCfMfyAw5LoUCY2WOUOkfWh7cTw== ARC-Authentication-Results: i=1; rspamd-7f9dd9fb96-75c8z; auth=pass smtp.auth=dreamhost smtp.mailfrom=adam@alphapapa.net X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|adam@alphapapa.net X-MailChannels-Auth-Id: dreamhost X-Power-Relation: 4f6c157b51edc740_1709187017842_3614075182 X-MC-Loop-Signature: 1709187017842:2206351338 X-MC-Ingress-Time: 1709187017842 Original-Received: from pdx1-sub0-mail-a300.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.117.236.39 (trex/6.9.2); Thu, 29 Feb 2024 06:10:17 +0000 Original-Received: from [10.28.0.58] (unknown [45.131.192.18]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: adam@alphapapa.net) by pdx1-sub0-mail-a300.dreamhost.com (Postfix) with ESMTPSA id 4Tlgn46bRpz4w; Wed, 28 Feb 2024 22:10:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1709187017; bh=4pOr1wWb2ZfYRhPPQfqv/GKixFVzc02iGB2ZEWlOZgI=; h=Date:To:Cc:Subject:From:Content-Type:Content-Transfer-Encoding; b=V0WSOxbINldWU4DpWjwNy9XHVKspJt2dMIDmNmOt0wOugjQvyqX1G6fagwcTtrbzT HQ1uGg80zCC0TVHjpIqoIW9CKD695XUsjPa9ifTLrmKMuals0cTTawtoPgqrgmV0qS X7PORIQbyFWMoQcvhrP+i2trEQdMvrSfcrT8YsvFVPyqX2LshehMm+Lei07ljFFUVQ sAOysVqc6di+rEzJvRq7RSbbl72N8uY/ucG2tHJ7foyD3vRN6RfGtRe7BQ6i6FYZd5 +kpSrOM70gc+2XDjskAsyFOrPjUG2Oj2PV1C890pZnr3i3Lh8n0zCzfLePjLmaWIyM bqdkaKIbquQZA== Content-Language: en-US In-Reply-To: Received-SPF: neutral client-ip=23.83.212.47; envelope-from=adam@alphapapa.net; helo=cyan.elm.relay.mailchannels.net X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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:316636 Archived-At: > > I worry that these declarations will become frequent, even pervasive, > > and then effectively compulsory. Then we won't have Lisp any more, > > we'll have something more like C. > > > I think somebody said somewhere that the declarations will be > > "voluntary", but things that start off voluntary have a nasty habit of > > first becoming pervasive, then all but universal, and then compulsory. I don't think these are fair arguments. They're beyond speculative. We're here because we want to write this kind of software in Emacs Lisp, not in C. No one wants mandatory type declarations. And the Common Lisp model, which Andrea seems to be inspired by and generally following, does not make such declarations mandatory either. The same kind of argument could be made about, e.g. Edebug instrumentation declarations: "If we allow macros to have these, they could start off voluntary, but then become pervasive, then compulsory. So we'd better not have them at all, then." Obviously, they have not turned out that way; they are added where they are useful and needed, and they are of great benefit. No one has any intention of making them mandatory; if they are not provided, then the macro is simply not instrumented as usefully. There is no slippery slope here. In the same way, if a function has type declarations, and--someday--the compiler could use them to produce more efficient code, that would be great. Otherwise, the function will be compiled as it is now. This is, as far as I can tell, what Andrea has always intended to do, time permitting, and he has made this clear from all of his writing on the topic for the past few years. To suggest that he intends otherwise would seem quite unfair to him. > That is my concern as well. If we let native compilation > lure us down the path of changing the Emacs Lisp language > so as to make native-compiled code faster, there is almost > no limit to how much time we could put into it. There are > always things we could do to keep optimizing some cases. > > This will tend to draw effort away from other sorts of improements in > GNU Emacs. We should decline to go down that path. I don't think that's a reasonable way to view this matter. Emacs is developed voluntarily. It's a rare occasion that someone comes along who has the expertise, interest, and time to contribute something as challenging as compiler optimizations, such as Andrea has graciously given to us (really, a whole new compiler implementation). When it happens, who are we to say that they should apply their effort elsewhere. We should gratefully accept their contributions and encourage more of them as they are able to provide. Emacs needs these kinds of significant developments--ones which happen rarely but provide benefits for many years--to sustain it in the face of competition that's developed by teams of full-time engineers working at large companies. Woe unto us if we turn them away by asking them to volunteer their time on something not according to their interest.