From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.devel Subject: Re: Help sought understanding shorthands wrt modules/packages Date: Tue, 22 Nov 2022 11:37:22 -0800 Message-ID: <871qpubx1p.fsf@rfc20.org> References: <651bbe21-f179-730a-4f10-7dc6d27055ea@gmail.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="37161"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= , Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 22 20:38:19 2022 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 1oxZ62-0009Qy-TY for ged-emacs-devel@m.gmane-mx.org; Tue, 22 Nov 2022 20:38:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oxZ5L-0001zY-AN; Tue, 22 Nov 2022 14:37:35 -0500 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 1oxZ5I-0001zO-TI for emacs-devel@gnu.org; Tue, 22 Nov 2022 14:37:32 -0500 Original-Received: from relay11.mail.gandi.net ([2001:4b98:dc4:8::231]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oxZ5G-0001QN-BW; Tue, 22 Nov 2022 14:37:32 -0500 Original-Received: (Authenticated sender: matt@rfc20.org) by mail.gandi.net (Postfix) with ESMTPSA id 5E9AA100004; Tue, 22 Nov 2022 19:37:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rfc20.org; s=gm1; t=1669145847; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IAeuBCKFj6icxutrFT2Y0twdHCWK7N78l4g5mW+n83A=; b=h52ZU9y9Ny3A7s7y9NZg+2Gaav1F1GRhjYl8nfHwleUKRA2m+2swYn/q2NaVwRMyv4Y5wf /zI/c6/P1T9l6fOSV3M6uBhSwEo/bCr/E+Co3Q2tEkGD3G2S4cmB9dPGMm8HVwoXqRSB7Z DYH8zKBnJNqR0G8U3X7AsPetVs85O8I/Y0wqbh9WpV+WHb+tuWYoO/H+ZUTwCOwR8sQ48+ /SeRJTMeiNzT08fW/ej5HQK7xF2OmVfciQbyZgf/yyNNCyCwFxH7cMyJHyHtDznXO4iR2f SLU6Q7albleXL3FSt+xMFGC6x91mfZ6iwVoKvpCsV5NDDMv4KJ9teqm/Itjgpg== Original-Received: by mac-mini.lan (Postfix) with ESMTPS id 024253A946; Tue, 22 Nov 2022 11:37:23 -0800 (PST) Original-Received: by naz.lan (Postfix, from userid 1000) id CF53A43C005A; Tue, 22 Nov 2022 11:37:22 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2001:4b98:dc4:8::231; envelope-from=matt@rfc20.org; helo=relay11.mail.gandi.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, 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:300346 Archived-At: Gerd M=C3=B6llmann writes: >> The grave problem of :USE in CL packages could be fixed by replacing >> it with a new construct that specifies a list of symbols to be >> inherited from each other package, perhaos with renaming. > > I fail to understand the "grave" problem, sorry. Could you please give > a more concrete example? A few weeks ago, in this thread or another, I attempted to explain my understanding of the point Richard was raising. As far as I can tell I still share the same concern Richard raises. The issue is that `(use-package "A")' brings all of A's exported symbols into the current namespace, and so allows them to be used unqualified. This implies that any addition to a package A's exported symbol list has a chance of breaking code in any package that "use-package"'s it. The breakage takes the form of an introduced ambiguity. This is a problem for "programming in the large". If package's can't add new things without risking breaking their users then the approach is arguably worse than Emacs' current approach, at least in this respect. Adding a new name for a new piece of functionality is one of the most common ways packages evolve over time. > BTW, in CL, if you don't want to use-package you can also import just > the list of symbols you want. Without renaming, but I guess that > could be added, if somone wants that. (I mention the idea of renaming > in cl-packages.org, BTW, on the branch, but I'm still not sure it's > worth it.) Yes, Common Lisp provides ways to fix things *after* the breakage occurs, but the harm comes with the breakage, and is an inevitable consequence of the design. Yes, the danger can be avoided by refraining from using `use-package' at all. This is the root my suggestion to consider CL packages for Emacs but subtract `use-package'. Yes, this kind of problem exists not only in Common Lisp but many other languages, to the extent that some might come to believe this sort of problem feels "natural" or is perhaps worth it for the convenience of using unqualified names from other packages. Python's "from foo import*" is like CL's use-package and is now widely considered poor style in the Python community (for the reasons I've stated). Guile has something like Common Lisp, with the same problem and the same kinds of mitigating workarounds. Ada has "use" with semantics similar to CL's. Perl has "use" but, presumably through experience, recognized a problem and has a "use VERSION" mechanism to limit potential harm from API changes. And on and on. The argument is that all of these languages are all flawed in the same way, and that a package/module system designed today should aim for better. There are languages that avoid this problem. Java avoids it, as does Go, and as far as I can tell Rust does too. These languages simply do not providing a way to slurp entire namespaces into other namespaces. In these languages referring to names in other packages requires either a package name qualifier, which can be renamed locally to something short if desired, or by explicitly pulling individual names, one by one, into the current scope. With this there is no way for an addition of a name in one package to cause a naming conflict or ambiguity in any other. >> Eli wrote: >> >> > Moreover, from my POV, the jury is still out on the question of >> > whether we at all need packages in Emacs. "Programming in the large" >> > doesn't sound very relevant to how Emacs Lisp is used. >> >> I share this feeling, except that I take it a bit further. In the >> 1980s I thought about whether we should have packages in Emacs, and >> concluded that using a naming conventions is simpler, easier and more >> flexible. So I chose that. >> >> If CL packages were unproblematical, I'd say, "Sure, why not? We >> aren't desperate to keep Emacs small nowadays." But they are >> problematical, and that is a reason to choose to do without them. > > Please spend some effort to explain the problematic cases. Done, I think. I suspect you already understood the point, but merely disagree about its importance? To Eli's "jury is still out" point: So far I have not seen a clear description of the problems with Emacs' current approach, so there is not even a common understanding of what the problems are, much less any consensus over how serious they are. Without that, I think there is little hope of weighing different alternatives productively. As far as Common Lisp style packages, well, Common Lisp is a stable set of compromises designed to unify disparate lisp implementations in the 80's. It is stable and well understood, which has some benefits. But it is not clear to me that, when considering designs for Emacs today, that there is any sort of "implied fitness for purpose" that comes from Common Lisp designs. The question and problem of adding a packaging system to Emacs today strikes me as a very different thing from the kinds of issues and problems originally considered in the 80's for Common Lisp. Specifically, back then "use-package" may have been a compromise seen as a necessary, pragmatic, but suboptimal solution to some problem of the day (e.g. perhaps making old code work without much change while still retrofitting a package system). It isn't obvious to me that Emacs has the same problem(s) or that it should, necessarily, adopt the same solutions.