From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: What's missing in ELisp that makes people want to use cl-lib? Date: Thu, 02 Nov 2023 21:26:00 +0000 Message-ID: <87bkcbrgnr.fsf@posteo.net> References: <46ab3c7d-d820-4bb4-8ec4-97c614d7c8a0@alphapapa.net> <871qd8sfdx.fsf@posteo.net> <838r7g8pys.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5148"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, joaotavora@gmail.com, adam@alphapapa.net, emacs-devel@gnu.org, stefankangas@gmail.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 02 22:26:57 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 1qyfDL-000159-KF for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Nov 2023 22:26:55 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qyfCe-00063X-Q3; Thu, 02 Nov 2023 17:26:12 -0400 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 1qyfCd-000637-Bq for emacs-devel@gnu.org; Thu, 02 Nov 2023 17:26:11 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qyfCa-0008Vg-3j for emacs-devel@gnu.org; Thu, 02 Nov 2023 17:26:11 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id EC7F5240028 for ; Thu, 2 Nov 2023 22:26:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1698960364; bh=uYe7nfIs5Ekx8ZM51s8t21jDNnoRx3DTlh2zGtL7QJU=; h=From:To:Cc:Subject:Autocrypt:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=QckNoSSUjIjM3dmGWy1zsRitCnoho/8iWo1x9pJjE+DKsd0qD0W8htmavX7xBzt50 4HlCEpIg98kVFDBo8LHW56aL7RYagbp1z1PVHzJ3y2vnBIv/zqxJr2VRiqPngiPBMc jXZjIBK1gy3YCqPy7FXondd/HCO4PFWGuNxQf+EnS7+SVaOPR5LFd0eHECUcBCDNcQ wH4ihioZn8ophoyaFM6J//4ammQ6rcR3nar6asAHoYHt2UlVTniaCLfnFj5hfSLhcV Jsc+nds0RN8gDniB30ow0PpBwFNDEbVXczlraHnKu0zAn8jv5bLUORRGPvKbCuS50o pxlfLg3T4IahQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4SLxkf5Ql7z9rxF; Thu, 2 Nov 2023 22:26:02 +0100 (CET) In-Reply-To: <838r7g8pys.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 02 Nov 2023 11:27:39 +0200") Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable 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:312137 Archived-At: Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: Jo=C3=83=C2=A3o T=C3=83=C2=A1vora , >> adam@alphapapa.net, emacs-devel@gnu.org, stefankangas@gmail.com >> Date: Thu, 02 Nov 2023 08:55:54 +0000 >>=20 >> Richard Stallman writes: >>=20 >> > It might be ok to add some keyword arguments to `sort', which are more >> > unusual and complex to use, but not to simple constructs like >> > `pushnew'. This is Emacs Lisp, not Common Lisp. >>=20 >> What does that last sentence mean? > > AFAIU, it means that Emacs Lisp traditionally doesn't use keyword > arguments, except as relatively rare exceptions. It is used rather prominently in `define-minor-mode' or `define-derived-mode', or do you specifically mean keyword arguments to functions? >> what constitutes "Emacs Lisp"? It would >> seem peculiar if it were to be defined by the arbitrary decisions of the >> past, constrained by the contingent circumstances of the time. > > Those "arbitrary decisions" are what got us to where we are now, 40 > years later. So some respect for those "arbitrary decisions" is due, > I think. No disrespect meant, but I am not sure we are thinking of the same things. An "arbitrary decision" usually doesn't matter much, like calling a function rplacd or setcdr. If a decision got us to where we are now, I would say it wasn't that arbitrary, but a good one? >> to me the main aspects and attractions of Emacs Lisp (in contrast to >> CL and Scheme) have been: >>=20 >> 1. Not standardised; it is possible to extend the language without >> having to worry about how many implementations will follow along > > IMNSHO, extending Emacs Lisp as the language is not the main goal of > Emacs development. Emacs Lisp is not a programming language on its > own, it is a language for implementing and extending features and > extensions in Emacs. Thus, the main goal of Emacs development is to > develop applications and application-level features, and provide more > opportunities for extending the core where that is considered useful. > What we have in Emacs Lisp is IMO ample for that purpose. Moreover, > most participants in Emacs development are not experts in programming > languages, their expertise is elsewhere (which is definitely a Good > Thing). Of course not extending it for its own sake, but I would assume that making it easier for users to write practical and useful code should be something that is valued. > Objectively, adding new syntax and semantics to Emacs Lisp does make > the source code harder to read and maintain, because it makes the > language larger and requires familiarization with those new language > features, which more often than not look and feel completely different > from the "traditional" Emacs Lisp. So even if we conclude that these > additions are worthwhile, we should not pretend they come without a > price, and IMO we should think carefully whether their use is > justified before we use them in each and every case. Could you explain what you mean by "traditional" Emacs Lisp? But yes, I am not advocating for senselessly adding whatever seems remotely interesting, of course. >> Emacs Lisp can learn from interesting ideas that other >> languages provide, adapt and add them, making them available to >> everyone. > > It certainly can. The question is: should it? Since we are not > driven by any standard, it is completely up to us to make those > decisions, and we should IMO make them judiciously and carefully, > taking the downsides into consideration. In particular, I hope people > agree that making a language too large and complex is not a good > thing in the long run. > >> If a form expresses something that people frequently want to >> do, but either have to elaborate using (unless (memq ...) (push ...)), >> then we are making Emacs more useful and expressive by providing the >> functionality OOTB. And isn't that the real point of Emacs Lisp? > > AFAIU, what Richard says is that if some form is frequently used, we > should indeed consider adding a primitive or an API for it, but that > primitive or API doesn't have to look like CL. Cf the pushnew > argument. Right, I agree with everything here. The functionality, not the style is of interest.