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: Tue, 12 Sep 2023 14:32:05 +0200 Message-ID: <87h6nzfu7u.fsf@dataswamp.org> References: <87ledwx7sh.fsf@yahoo.com> <877cpfybhf.fsf@yahoo.com> <873503y66i.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21176"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:nWaCaL2OStPmpgTiT3lam9WgisE= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 12 16:36:30 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 1qg4VB-0005HN-Uq for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Sep 2023 16:36:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qg3Ar-0005B4-Va; Tue, 12 Sep 2023 09:11:26 -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 1qg2Yz-0005QK-Qb for emacs-devel@gnu.org; Tue, 12 Sep 2023 08:32:17 -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 1qg2Yx-0005ZG-78 for emacs-devel@gnu.org; Tue, 12 Sep 2023 08:32:17 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qg2Yv-0006dm-6E for emacs-devel@gnu.org; Tue, 12 Sep 2023 14:32:13 +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: Tue, 12 Sep 2023 09:11:24 -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:310522 Archived-At: Arthur Miller wrote: > Of course, but nobody suggests it is all-in. `length' is not > a keyworded in CL either. It would be madness to do > something like naming all arguments in all functions. But it > is convenient to have keywords in some places [...] Keywords typically make for shorter interfaces and function calls that communicate more, however the shorter interface advantage and the need to have function calls to communicate more should be put against the typical downside with this style, which is very long and complicated functions that do a lot more than they should, often. And, because very long functions isn't good style anyway, those should probably be split up - and if they are split up, the interfaces will be shorter and the style clear that way instead, so the need for keywords to do that will also be reduced or disappear, really. >> Defining the CL functions with a name prefix is ok, because >> the traditional Lisp functions are still available >> compatibly and we don't have to use the CL functions. >> This is what we have now. > > If cl-lib was loaded into the lisp image, we could even > rename cl-defun to defun, after we have initialized all the > other stuff that goes into the dump, and have "upgraded" > vesion of defun and would be fully compatible with > traditional Lisp functions. We could even go further and > remove cl- prefix from bunch of symbols to make them less > cumbersome to use, and everything would stil be compatible > with traditional Lisp functions. Indeed, that could be done for every cl-X case where X is a non-cl-lib Elisp function and cl-X already does everything X does with the same interface. Those could be cancelled out. For the cases where there is no such X outside of cl-lib, e.g. `cl-incf' and `cl-decf' (no "incf" or "decf" anymore?) the cl-lib prefix could also be dropped. Another example is `cl-loop'. One could solve this with aliases, possibly. Because yes, it looks a bit strange that such rudimentary stuff has to be prefixed to note their belonging to some particular implementation or library, and even more so when there isn't any competition or alternative, even? -- underground experts united https://dataswamp.org/~incal