From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: What's missing in ELisp that makes people want to use cl-lib? Date: Thu, 2 Nov 2023 11:07:31 +0000 Message-ID: References: <46ab3c7d-d820-4bb4-8ec4-97c614d7c8a0@alphapapa.net> 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="37882"; mail-complaints-to="usenet@ciao.gmane.io" Cc: adam@alphapapa.net, emacs-devel@gnu.org, stefankangas@gmail.com To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 02 12:08:41 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 1qyVZ3-0009be-DU for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Nov 2023 12:08:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qyVYH-0003Yl-NL; Thu, 02 Nov 2023 07:07:53 -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 1qyVYC-0003Sx-I6 for emacs-devel@gnu.org; Thu, 02 Nov 2023 07:07:50 -0400 Original-Received: from mail-lf1-x134.google.com ([2a00:1450:4864:20::134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qyVYA-0006M9-HQ; Thu, 02 Nov 2023 07:07:48 -0400 Original-Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-507c5249d55so946851e87.3; Thu, 02 Nov 2023 04:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698923263; x=1699528063; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5foH7/fmlmoh9ILivy2gUAhPUarZHQcAlCdq2AZJPp8=; b=jo3vylh/jSdoQwZtZcyquw1PDyQsQFE8UIw/D5rUvOK9iT+UKDWo42Amtn0Vm5zL6q lv5Bcao1qeGfkTYuJ1rusLTGFWUj2eR6Ab5n11GNy3yg5xmOFebQzGQGFobjzy08JiB/ BKi1ju7mCdgRWxgAOwO0PtWZB0h1PP84K6QpfSGH6Gz57wBoNEgl6s3QTeCoH+u4lisv PCIT/BTPT32Xg6WB1aNKOay+YjB+2oekJUmR7omEu1fvfM/vjnxFzNO12ANjkHjH+NKe cMAv3Rl5uXRrs4/ZDwaBSz1QwnzACj7IUkI6oHzG53tdqochkGUSjVT+iKr4jj6hAbbJ hJXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698923263; x=1699528063; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5foH7/fmlmoh9ILivy2gUAhPUarZHQcAlCdq2AZJPp8=; b=untYJB+8b+6hMWZsvb8upN92gu48ZC3P3dzcQwfJeGA36hOB4FBlfB7V/dgTgozk4A i/YEvLDskQ4NPrnoiC+hMsSZAA+TstPXRp1ucztnNrWpNdrsEnw5hKtD8wt0Qw8kfAlZ Ob7tt6HDvYlBeUWr1+cFMPpGT7mtv9e41C9FkdT1HiqfkDz63i+7oAutQiau/16UusTv ieqUu3Q9OnecERncbtlsHlsgCkRjhhQ0HzV/zVLP4P0D80dj10P/Gew67m2h81xUeWRC +Nkow9HGyrI/M8bBKWz2kIVHjaWgcN6U/XFE3Po8bDXw0B7yNbxF+g8UQm6dCbgD1q0Y J1Fw== X-Gm-Message-State: AOJu0Yw+DyzpOt2hPueSXWNlNB53zJTEZodeJxtlA2YKdFhTU2bLzAYz SQTw6kQVpjiuIbdhUvDHmbRDFZ+y1PRezrgKw4U7f/lxldk2UA== X-Google-Smtp-Source: AGHT+IGMiWe7K8l8iFSH/cZdt3YITR5MUOMjV1yzgrL59hpLgTD15bAxyCCwFKPWGrakRKbNfOI/3tkdfymBdiBbqxs= X-Received: by 2002:ac2:5234:0:b0:4fd:c844:6a43 with SMTP id i20-20020ac25234000000b004fdc8446a43mr14332005lfl.43.1698923263014; Thu, 02 Nov 2023 04:07:43 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::134; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x134.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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:312112 Archived-At: [ Richard, with this message, I am also replying to your message in the other thread ] On Wed, Nov 1, 2023 at 1:48=E2=80=AFAM Richard Stallman wrote= : > > Anyway, the point is that to hack on long-lived files > > such as lisp/minibuffer.el, one can't really "ignore" the new > > dictionary of seq.el anymore. > > That's exactly the problem. Then why this laser-focus on cl-lib.el? Why not criticize the use of seq.el and map.el and pcase.el all of which "add many functions, which have many details"? Why are these libraries seemingly exempt from this discussion? The above question is mostly rhetorical, I am _not_ criticizing these libraries or advocating restricting seq.el and map.el and pcase.el. Reading certain parts of Emacs core has become impossible without getting well acquainted with Stefan's Monnier pcase.el which I had to do some 7-8 years ago. It was an entirely alien creature when I first saw it. It is directly inspired by pattern matching of the ML language. When reading a pcase, I occasionally think to myself that it's overkill complexity, that "in the old days" it was all much simpler. In many other cases I've learned to appreciate, and now it's part of my Lisp toolbox too. I think it's important to allow the programmers and maintainers working on specific sections of the code a certain freedom to recommend or select certain abstractions. But Emacs's Lisp code base is now very extensive and any kind of core-wide ban or rewrites of certain patterns is counter-productive and highly contentious. Let's be very careful when going down that path. On Thu, Nov 2, 2023 at 2:28=E2=80=AFAM Richard Stallman wrote= : > > 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. Adding keyword arguments to a given function doesn't transform Emacs Lisp into Common Lisp in any meaningful way. Just as translating a work by Shakespeare into Portuguese doesn't transform Portuguese into English. It just allows Portuguese speakers to enjoy some very decent, maybe even essential, poetry. Has Emacs Lisp become ML through the use of pcase.el? Of course not. It's become easier to write many things in Emacs Lisp, if anything. Frequently, the argument advanced for not wanting to import feature A or B from this other language, is "Emacs Lisp is to be kept simple and not have this complexity". Fair enough, programmers' craft is foremost about managing complexity. So very often a decision to simplify here and now breeds enormous complexity elsewhere later. Simplicity that proved effective and beneficial 30 years ago, in a different context, might not really be those things today, or 30 years from now. For example, the early decision not to have namespaces in Emacs Lisp, taken in the name of simplicity, may have facilitated development of Emacs features in a time where there were reasonably few packages. But as the ecosystem grew, it created -- and still creates -- many challenges. For example, one of the challenges it creates is this discussion right here: to be able to easily delimit what that "core" or "standard" Emacs Lisp is -- which is what Philip Addressed. There is in fact no such thing. This is _not_ necessarily advocating for namespaces/packages in Emacs Lisp, it's just my way of pointing out that the argument of "simplicity" is much more nuanced. Is a keyword-argument-less 'pushnew' simpler than 'cl-pushnew'? Yes it is, undoubtedly. Will the former breed less complexity than the latter? Very unlikely IMO. Instead we should look at how much more complex than the hypothetical 'eq'-comparing version of 'pushnew' is `cl-pushnew` in the end. In the argumentless version it's exactly the same. When a keyword argument _is_ needed (say we need to test with #'equal or #'my-special-comp) doesn't that increase in complexity pay off three-fold almost immediately? IOW versatility of a given utility must obviously be taken in consideration. By the way, if it hasn't yet become apparent to you or other readers, the keywords usually accepted to cl-sort, cl-pushnew, etc all belong to a fairly small dictionary with consistent meaning. For example, the ':key' accepted by 'cl-sort' tells the thing to consider when comparing, and the ':key' accepted by 'cl-pushnew' also tells the thing to consider when comparing. It is not more useful to 'cl-sort' than it is to 'cl-pushnew'. Keyword arguments are IMHO one of the most elegant mechanisms to promote maintainability, and generally typing less code. Of course, there might be other possible, unique and original ways of achieving the same of course, just as pcase.el showed me there were other ways of doing destructuring. But choosing any one option just for the sake of "not being like any other language" is not the right path to take. Jo=C3=A3o