From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: Shrinking the C core Date: Sun, 17 Sep 2023 11:13:42 +0200 Message-ID: <87jzspcgc9.fsf@dataswamp.org> References: <87il8betof.fsf@dataswamp.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="29908"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:EIQcck0v1eS5ZOjKET5n42FlbSU= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 17 11:16:01 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 1qhnsn-0007bd-0q for ged-emacs-devel@m.gmane-mx.org; Sun, 17 Sep 2023 11:16:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qhnsP-0006TE-BV; Sun, 17 Sep 2023 05:15:38 -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 1qhnqt-0006DN-QW for emacs-devel@gnu.org; Sun, 17 Sep 2023 05:14:04 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qhnqr-00029D-HI for emacs-devel@gnu.org; Sun, 17 Sep 2023 05:14:03 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qhnqp-00059w-Cc for emacs-devel@gnu.org; Sun, 17 Sep 2023 11:13:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 17 Sep 2023 05:15:35 -0400 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:310658 Archived-At: Alfred M. Szmidt wrote: >>> We have them in Elisp as well, `cl-remove-if' and >>> `cl-remove-if-not', both in cl-seq.el. >> >> A partial emulation of some Common Lisp functions is >> present in the cl-lib library, for emulation purposes. >> It is not supposed to be used a lot. > > And if there are functions or features that make sense from > Common Lisp, they can always be added piecemeal. There is no > need to make Emacs Lisp complicated for the sake of > compatibility with Common Lisp. I don't know why cl-lib was added to GNU Emacs and Emacs Lisp, maybe it was, as you say, for emulation purposes and for the sake of compatibility with Common Lisp. But the way it is used today, as we just heard in 28% of vanilla Emacs files, isn't because of CL emulation or compatibility purposes, but because it adds useful features and covers aspects that non-cl-lib Elisp leaves blank. For functions like `cl-incf', where there is no corresponding "incf" [I don't know whatever happened to it or why it was dropped, or maybe it wasn't ever there before cl-lib?] one could setup aliases or simply drop the "cl-" prefix (and set an "cl-incf" alias to the new "incf" as not to break existing code). Then, for functions like `cl-defun' and `defun', one would examine if those could be merged into a new "defun", with the CL features brought over, e.g. the default &optional argument value syntax. Here one would again use aliases to cover the back. For functions that cannot be merged because they are inherently different, if such cases exist, one would keep the "cl-" prefix and the incompatible non-cl-lib Elisp function. But one could also just leave it the way it is! Since those prefixes are hardly a big problem. And especially not compared to all the good features cl-lib brings to our game. -- underground experts united https://dataswamp.org/~incal