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: Fri, 03 Nov 2023 07:48:21 +0000 Message-ID: <87sf5nwa4a.fsf@posteo.net> References: <46ab3c7d-d820-4bb4-8ec4-97c614d7c8a0@alphapapa.net> <871qd8sfdx.fsf@posteo.net> <838r7g8pys.fsf@gnu.org> <87bkcbrgnr.fsf@posteo.net> <83r0l771rl.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="37268"; 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 Fri Nov 03 08:49:25 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 1qyovl-0009Su-4I for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Nov 2023 08:49:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qyour-0006Wx-Pr; Fri, 03 Nov 2023 03:48:29 -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 1qyouq-0006W7-AF for emacs-devel@gnu.org; Fri, 03 Nov 2023 03:48:28 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qyoun-0008CG-Lx for emacs-devel@gnu.org; Fri, 03 Nov 2023 03:48:28 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 3F97C240103 for ; Fri, 3 Nov 2023 08:48:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1698997703; bh=JZSQLt5ykXLX2SlrWWuoxH6f49Lhen2WorsPEqqMcgc=; h=From:To:Cc:Subject:Autocrypt:Date:Message-ID:MIME-Version:From; b=PDoIzT/rUMROml932dR8QWGFKwG11PGHWLK6Cg2af1ojX2OP1sN+nuNw/Kf5jzbwo CYzEmEBvmCUnemWXju12VXFe4X7OSskIwHIswXEIXumWBIlXrCBa+J1/8KWxIOpJDY TmB5ouRgUXtB1dpVwOPkkx8+AfQvA6PNYskyb3vJSh8eFlxY+DUS6jxnEAl31eMBGx 8+C9DYctkrq7SYUk+bMMp9Xd7fRI3kxFVlb2ItpNwWcoFlCGOBm6oF6wVjZTEdkUI6 XsfdRfGEAp546vrbMUcIp8SLVQX5hl3z3NOP4xwgonugqIMq3gZ56Q9ypud5X3asHS Pb6K6lTM896kQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4SMCXk12bjz6tvZ; Fri, 3 Nov 2023 08:48:22 +0100 (CET) In-Reply-To: <83r0l771rl.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 03 Nov 2023 09:07:58 +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.66; envelope-from=philipk@posteo.net; helo=mout02.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:312150 Archived-At: Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: rms@gnu.org, joaotavora@gmail.com, adam@alphapapa.net, >> emacs-devel@gnu.org, stefankangas@gmail.com >> Date: Thu, 02 Nov 2023 21:26:00 +0000 >> >> Eli Zaretskii writes: >> >> > 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? > > I did mention exceptions, didn't I? > > And define-derived-mode supports keyword arguments only since Emacs > 22; the original implementation didn't. Ok, I interpreted this as in "few usages", not in "few definitions". >> >> 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? > > Exactly my point. So what did you mean by "It would seem peculiar if > [what constitutes Emacs Lisp] were to be defined by the arbitrary > decisions of the past"? That "setcar" is supposed to be more Elisp-ish than "rplacd", or things like that. >> > 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. > > We should consider such additions carefully, weighing their advantages > against the disadvantages: introducing "alien" syntax, making the > language larger, etc. What I had in mind were extensions like the recent `with-restriction'. Defining something like this came to my mine on more than one occasion when combining `save-restriction' and `narrow-to-region' in exactly the same pattern as I had done many times before, because it seems natural to have it combined in a single form. I don't think this is necessarily alien, perhaps even natural in the long term. >> > 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? > > Basically, the language as it is, without macros whose syntax is > different from Emacs Lisp. For example, cl-loop has syntax that to my > eyes is starkly not Emacs Lisp, because it uses many keyword-like > parts that look like they were lifted from Fortran. Then again (cl-)loop is a peculiar example; even among CL programmers there are many that dislike using it on the same grounds. As a macro, it doesn't really even attempt to blend into the surrounding language, but uses special keywords and syntax parsing, that has both its advantages and disadvantages, but it is still used if only because CL doesn't have a simple `while' macro. This is a much more stark example than pushnew. I could imagine that pushnew could be implemented without a keyword argument, if we accepted three arguments (newelt place compare-fn). But there are a plenty of definitions in cl-lib that in some form or another I think would be nice to have in Elisp proper as well: list*, flet, defmacro/defgeneric, defstruct would be some examples that come to mind. This is not only my personal perspective, but the feeling I get from reviewing Elisp packages that include cl-lib for only two or three definitions.