From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: What's missing in ELisp that makes people want to use cl-lib? Date: Tue, 07 Nov 2023 11:18:05 -0500 Message-ID: References: <46ab3c7d-d820-4bb4-8ec4-97c614d7c8a0@alphapapa.net> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36908"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 07 17:18:33 2023 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 1r0Ome-0009R6-7O for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Nov 2023 17:18:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0OmK-0002dO-Vs; Tue, 07 Nov 2023 11:18:13 -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 1r0OmE-0002Wo-E7 for emacs-devel@gnu.org; Tue, 07 Nov 2023 11:18:07 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0OmD-0005mU-OP; Tue, 07 Nov 2023 11:18:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=MUyaM0wUn9420IB8USFbcyBQqOIVpcniqGD1Hv0DQD8=; b=ULwvusk5qRa8 FdzDZ0bq7vOiFmbqsd1R8zCW7RUuEkE6tk5plFAFy4r5qP+uDDdyurr8aHkka4BMycTCKFtj/5qO1 flasDyuAipaaZWCHtjx61wSIJsJZj014dqZzyeNh+dQ6p8F8Lo1JycgqSb6afsZf7UniDwsGIa/G6 CGb2mWmO/IBtFNadDwQXNTeq5i3z01zPxUgmnISNLnwBSTqhNy/kZKEOuXralk8y8NFLymWC/sko9 WBeoulsyk8wHtXlurIezAcJd/wv78mnT/nQr9muNWRVh3jWavuA1A+OVyJWJvLbffTS+qZfZMdzVB AhxcjfysDyKr6Zcu2IBhUw==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1r0OmD-0001IJ-FL; Tue, 07 Nov 2023 11:18:05 -0500 In-Reply-To: (message from Drew Adams on Thu, 2 Nov 2023 15:20:51 +0000) 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:312313 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > There's a difference between (1) adding &key to > Elisp generally and (2) letting more functions > take advantage of :key and :test, in particular. That is a valid distinction. I would be happy to see a keyword argument facility provided for function definitions in Emacs Lisp. There are occasions where it is good for a function to accept keyword arguments -- especially those functions that need to accept lots of arguments. What I object to are the keyword arguments used in Common Lisp to call simple, everyday functions. For instance, the sequence functions. (For this reason, I prefer the seq- functions to the Common Lisp sequence functions.) But we can split that issue by making another distinction, between (2a) sequence functions that _accept_ the Common Lisp sequence function keywords, such as :key and :test, and (2b) frequently needing to pass those arguments. (2a) does not make most code any more clumsy. It affects only the _definitions_ of these sequence functions. What makes code ugly is (2b). Logically, (2a) does not force (2b), but the two are directly related. The designers of Common Lisp saw (2a) as providing an opportunity to "simplify" by eliminating the predefined functions to compare using `equal' and to compare using `eq'. By default they use `eql', which says "a pox on both `memq' and `member'." In practice, that makes the Common Lisp functions inconvenient to use. I would not be unhappy if Emacs Lisp functions started to support :key and ;test where they make sense, provided they did this in an Emacs Lisp way: default comparison is `equal'. (We should take care to implement it without a slowdown in the case where the keyword args are not specified.) This means that `member' would accept ;test, but it would still compare using `equal' by default (if :test was nil or not specified). And there would still be `memq' to compare with `eq'. When I say "new functions", that includes any Common Lisp functions that are currently available in cl-seq.el with a cl- prefix but NOT treated as part of Emacs Lisp. To treat them as part of Emacs Lisp, we should make them compatible, we should (1) make them default to Emacs Lisp tradition and (2) accompany them with a corresponding q function, if comparing using `eq' is useful for that function. We would also rename the function, as part of the bargain, to avoid an incompatibility. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)