From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tomas Hlavaty Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: Shrinking the C core Date: Tue, 12 Sep 2023 21:52:32 +0200 Message-ID: <87msxrkw3j.fsf@neko.mail-host-address-is-not-set> References: <87ledwx7sh.fsf@yahoo.com> <877cpfybhf.fsf@yahoo.com> <873503y66i.fsf@yahoo.com> <87pm2oe9a0.fsf@neko.mail-host-address-is-not-set> 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="19558"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, Drew Adams , arthur.miller@live.com, acm@muc.de, luangruo@yahoo.com, emacs-devel@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 12 21:53:27 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 1qg9Rv-0004lK-Iu for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Sep 2023 21:53:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qg9RB-0006oS-Fj; Tue, 12 Sep 2023 15:52:41 -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 1qg9R9-0006mi-KQ for emacs-devel@gnu.org; Tue, 12 Sep 2023 15:52:39 -0400 Original-Received: from logand.com ([37.48.87.44]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qg9R6-0003pT-DN; Tue, 12 Sep 2023 15:52:39 -0400 Original-Received: by logand.com (Postfix, from userid 1001) id 1EE3C19E739; Tue, 12 Sep 2023 21:52:34 +0200 (CEST) X-Mailer: emacs 28.2 (via feedmail 11-beta-1 I) In-Reply-To: Received-SPF: pass client-ip=37.48.87.44; envelope-from=tom@logand.com; helo=logand.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham 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:310524 Archived-At: On Mon 11 Sep 2023 at 22:10, Jo=C3=A3o T=C3=A1vora w= rote: > On Mon, Sep 11, 2023 at 9:37=E2=80=AFPM Tomas Hlavaty wr= ote: >> not really, it seems that CL:SORT is a bad example > > The example was for comparing to Emacs's lisp 'sort', where > IMO it's much easier to do > > (cl-sort things-having-foo #'< :key #'foo) > > than > > (sort things-having-foo (lambda (a b) (< (foo a) (foo b)))) That has nothing to do with &key. It has everything to do with the lack of the KEY argument and the KEY argument could as well be &optional instead of &key. If you find lack of the key argument "much not easier", you can define your own sort, something like: (defun sort3 (seq pred key) (sort seq (lambda (a b) (funcall pred (funcall key a) (funcall key b))))) where (sort3 things-having-foo #'< #'foo) is "much easier to do" than (cl-sort things-having-foo #'< :key #'foo) or (sort things-having-foo (lambda (a b) (< (foo a) (foo b)))) Additionally, you'll get much nicer tool support automatically, e.g. autodoc tells me: sort3: (SEQ PRED KEY) cl-sort: (SEQ PREDICATE [KEYWORD VALUE]...) One can see that autodoc for cl-sort is severely crippled. > As to the advantage of @key key vs &optional key it is -- in my > eyes, at least -- that you already know its meaning from many other > functions. The point Richard raised was that your "many other functions" with &key are bad way of doing it. Simply naming the argument KEY would achieve the same goal of already knowing its meaning from many other functions. Making it &key does not change that. >> (btw why two functions and not extra stablep keyword argument?) > > Why not? Maybe that makes passing sort and stable-sort to higher > order functions more practical? That speculation does not sound plausible. By that logic, CL would probably define 4 functions: sort sequence predicate =3D> sorted-sequence sort3 sequence predicate key =3D> sorted-sequence stable-sort sequence predicate =3D> sorted-sequence stable-sort3 sequence predicate key =3D> sorted-sequence >> > Let's look at a traditional Elisp macro define-minor-mode. >> >> the usual CL argument list does not seem to be able to express arguments >> of such shape >> >> it looks like whoever extended the original argument list did it >> "weirdly" using custom ad-hoc single-use argument list parser. > > Quite likely the cl machinery wasn't available at the time... But yes, > Greenspun's 10th. > >> > are maintenance hazards, the macro now accepts keyword arguments >> >> in CL, the arguments would normally be in a list before body, something >> like >> >> (define-minor-mode MODE ([KEYWORD VAL ... ]) [DOC] &rest BODY) > > OK, but this is irrelevant. This is a macro, not a function. > For all practical purposes it was extended with keyword arguments. > In fact you could have used cl-lib's cl-destructuring-bind. No, that's missing the point. CL itself is not able to express the argument list structure in the shape it is implemented in define-minor-mode. You need custom argument parser anyway. autodoc for define-minor-mode is also useless: define-minor-mode: (MODE DOC [KEYWORD VAL ... &rest BODY]) The way define-minor-mode sneaks in keyword arguments is pretty bad. It implements custom argument list parser and makes tools that understand and work with argument lists useless, which causes extra manual work in other areas. If there was a unified argument list parser implemented in one place and used consistently, it would avoid lots of manual work. Back to the [KEYWORD VAL ... ] example, putting the argument list of the macro into an extra list would allow one to use unified argument list parser, but the way define-minor-mode arguments are specified at the moment, CL:DESTRUCTURING-BIND cannot destructure such structure (&key before &rest/&body is malformed). Another example, take &body as opposed to &rest. It automatically declares the intent and how the indentation is meant to be computed. With &rest indentation needs to be specified individually and manually per case. Lack of &body in elisp is annoying inconvenience. Example: (with-help-window BUFFER-OR-NAME &rest BODY) has (declare (indent 1)) which would not be needed if it was (with-help-window BUFFER-OR-NAME &body BODY). I think that rather than arguing about keyword arguments only, it would be better to push for a unified argument list format which would be followed, understood and supported by relevant tools. So far, argument list structure in elisp grew into ad-hoc mess which one needs to decode manually from docstring on case by case basis; and no amount of CL would help.