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: Lisp files that load cl-lib in problematical ways Date: Sun, 29 Oct 2023 16:31:36 +0000 Message-ID: References: <83ttqnm4ti.fsf@gnu.org> <831qdlpoye.fsf@gnu.org> <83sf5xhnym.fsf@gnu.org> <871qdhk49w.fsf@dataswamp.org> <25914.49745.111873.734458@orion.rgrjr.com> 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="27175"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Bob Rogers , incal@dataswamp.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 29 17:29:28 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 1qx8fI-0006tR-5s for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Oct 2023 17:29:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qx8ep-0003V7-Hv; Sun, 29 Oct 2023 12:28:59 -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 1qx8en-0003Ut-QH for emacs-devel@gnu.org; Sun, 29 Oct 2023 12:28:57 -0400 Original-Received: from mail-lf1-x12e.google.com ([2a00:1450:4864:20::12e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qx8eh-00030P-M4; Sun, 29 Oct 2023 12:28:57 -0400 Original-Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-507b9408c61so5095113e87.0; Sun, 29 Oct 2023 09:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698596928; x=1699201728; 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=xihRu6Uxt89LcC3uivaGJVcmco4nnVY5CBNAbZmQy8o=; b=CZSbRPsVH+JtLKvaKP/0JiM2MiaswUiz+lxq74YG9Yr18ni8F8DrqX3CWVKP0g8GxK ra7nX4+akYrtW2CpiMWqhLO3iMQZ5JBipamPDi+e5Uc0ud1h2ZN0LAvBNt/h1pfpJGAq KUD1KHvyU0uy0QYry5LSqqXrnl2Epf+4FsJBZI+4UConqfKVsopDR/OfWiy7H4eZouT0 QqJNKtWAkHOn7cUr0hexhnoUIhxwYCZN30KrLckdX919FdD+hDdpH2ohWFXzqPGCJBMB 0eQTi59EJj33LZvpENYweq16oCEY9REjZ8HugVXL/VF/NXXIo45Nrju7F6aqHl2OBqbu KXEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698596928; x=1699201728; 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=xihRu6Uxt89LcC3uivaGJVcmco4nnVY5CBNAbZmQy8o=; b=s9NkFF8kL2nkcbEEvCj+gkmZCPoWMxISA15FZX0PF66SGlRiTr8+Vh9qxn8CO610HA g21mrNfhsknKELIAfxnx2y3vqx5VfNWomfPuvo7iBIjHXtcWfS3YIYMvoSP3bpMTA/6e /2z6QPrGG4Pxa2xb8Mp+jdG0c/iVZGqJQkBNAm6Ox4Uuy5ZFTeNmxFUJ3ltOhLAHPMA2 wiFnwg3FX5uvzSqJjbBsM7NLAJrw3QJpSFRtmmUkFtSgKCty2ipOLQsekWnjmL+3at/h I0i/KuF8kwKfgPQG4H22Fx3ulJVbb9FZO7/4nIhbIvwbKlU/yID9qwD4D+3Xq4uP8ATx yV/A== X-Gm-Message-State: AOJu0YxgyfrGmzoEzx3SIyDZjVbJBAE3iTiCnkqoqfmwZItpPFxCcokr Peg7E1k8kUpqY16StmHwNESLMK6bOT4LF1UMQbxC1CZyrhecEw== X-Google-Smtp-Source: AGHT+IEiLBw9IJEMuvGSt4fDPV87RNMyIXV20164Stxkw5apCcKTrest9bcG/0rTxAmkCZI28AaBzEQcZgkGmyENerI= X-Received: by 2002:ac2:5185:0:b0:503:7dd:7ebd with SMTP id u5-20020ac25185000000b0050307dd7ebdmr4861682lfi.24.1698596927839; Sun, 29 Oct 2023 09:28:47 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::12e; envelope-from=joaotavora@gmail.com; helo=mail-lf1-x12e.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 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:311973 Archived-At: On Sat, Oct 28, 2023 at 4:20=E2=80=AFAM Richard Stallman wrot= e: > I think you've put your finger on it. > > I see nothing wrong with having an optional extension which implements > (more or less) Common Lisp in Emacs Lisp. That's what I thought we > had done. > > However, I object to incorporating (more or less) Common Lisp an essentia= l part > of Emacs Lisp. And it looks like we've been drifting into that. > > There is no sharp line between the one and the other, and no simple > test to determine which of those two our current situation actually > is. Rather, there is a spectrum that runs from "CL support is > available but you can ignore it" to "the CL constructs are an > essential and unavoidable part of Emacs Lisp." > > The specific practical questions I've asked are efforts to evaluate > where we are now along that spectrum. Of course, the answer to that > isn't precise either. But I was very surprised to learn how far > Emacs has gone towards the latter end. I'm going add my 2c here. I think this whole discussion, which I haven't followed very closely, might be slanted due to a misunderstanding. Most, maybe all, programming languages have two different ways they can evolve. One is to add or modify the API offered by their standard library by using the language itself, and another is to add or modify properties of the fundamental mechanics of the language by changing any of the runtime, interpreter or the compiler. The latter can't be done using the language itself. Now, Common Lisp has a number of features that belong to the latter group that Emacs Lisp doesn't have and there's no significant motion in that direction. Examples are a namespacing system based on packages, a programmable reader, a much more advanced condition handling system. I'm sure I'm forgetting some. In fact the only way that Emacs Lisp, the core language, has approached Common Lisp in recent years to any degree was through the addition of lexical binding, and I think that most people here would agree that was a very good thing. Well, maybe native compilation also counts. Then again, another very good thing, I suppose. cl-lib.el, like any other library, doesn't add -- because it really can't -- any features of that calibre to Emacs Lisp. It just adds functions and macros much in the way that lots of other libraries add functions and macros. For example, the seq.el library is another much later library (2014) that offers much of the same functionality of cl-lib.el in wholly new abstractions that, say, the 2000's Emacs Lisp coder won't be familiar with. Another such library is pcase. Does use of these libraries mutate Emacs Lisp programs to the point that they are unrecognizable as Emacs Lisp programs? Are the pcase macros fundamentally easier to read than, say, cl-case macros? Is seq's sequence manipulating dictionary better than CL's? Is seq-some really better than cl-some? Isn't that entirely a question of personal preference? seq.el is preloaded and nobody seems to care (and I also don't, to be honest). 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. If one were to compare apples to apples one could argue that CL's functions are _more_ accessible and quite well documented, since both the thought put into the design of those interfaces and the use they've seen by Lisp programmers of various breeds far exceed those of seq.el and pcase.el. Just my 2c, Jo=C3=A3o