From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Gerd_M=c3=b6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: Help sought understanding shorthands wrt modules/packages Date: Wed, 23 Nov 2022 08:42:56 +0100 Message-ID: References: <651bbe21-f179-730a-4f10-7dc6d27055ea@gmail.com> <871qpubx1p.fsf@rfc20.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39027"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Cc: emacs-devel@gnu.org To: Matt Armstrong , Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 23 08:43:29 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 1oxkPp-0009zT-0R for ged-emacs-devel@m.gmane-mx.org; Wed, 23 Nov 2022 08:43:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oxkPb-0005oC-5b; Wed, 23 Nov 2022 02:43:15 -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 1oxkPQ-0005nM-Gs for emacs-devel@gnu.org; Wed, 23 Nov 2022 02:43:07 -0500 Original-Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oxkPO-0003mO-KL; Wed, 23 Nov 2022 02:43:04 -0500 Original-Received: by mail-wm1-x332.google.com with SMTP id o7-20020a05600c510700b003cffc0b3374so723053wms.0; Tue, 22 Nov 2022 23:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:subject:from:content-language :references:cc:to:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=gg5zuCLYzEhdd6US5hJTepIsxDV6IQJmhtN5VMbTVw8=; b=FChZ1DxRNQB7Vd1/9PP1k6ML6p3p+/Gu1zwVoR+nGeknvbSMpsDsrAfJMYoFRh42iV RmQHrUVV6Q8oAEDsuZ8cDi3m0MQ0SgbLU4kO1VbQYspIcK3xkWSKWTlVynC7eWFpcs5D WBshUM60+Dd9EDqBLjkDWRfRRXuNYDGIRUeHNxrb9Olx+UdW0qAjTzH0hemidpB7BdO5 3I+HrsS3d37bEbCadBTtJ5tM2P0MLMpQZBGTmlGAnqpns8P7fA+VDcutFcBnLA8EX+k8 90ABHrxGe14IRzIkZF6A2vzCUshyvCFJ91J+6jVQl/rXXILd4IT3MVdsjrPm6b7ULqkB YMmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:from:content-language :references:cc:to:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gg5zuCLYzEhdd6US5hJTepIsxDV6IQJmhtN5VMbTVw8=; b=ooNzF9uHidnpdemtedvkrBYPx2zgY9MK8Ue66S0qX85fiOo3Gf0OARQF2FlERRkhtx RPG9Fw7A97FMN2DNuMdS7rGpnVQfDpKz0ufWd3cs6k9Iuwe/BO2ATjn5vE4xtyaqv9EQ hHTMLVXPr+xLZjSGaE0oIFS8vj0XpfQt6rjrQi8ljRoNJP3JJor8DvL7sPVKJGXNbtmo nATfswKs0xmwKa6lFkCd63HFhHVIEhrv8wAjRG90lhd0xoaRViEgOwbW9c6DdxgR/kNx AfEOwDtxOA0nR8tydgPgVOO6AuvgLSUFpc5m0aIcAq6gQDRB0ZbfJDxVJMPf75c6aV+F z5Eg== X-Gm-Message-State: ANoB5pmBvwbLoulPpcjUZ256tURAbUQo+F3URgHpoGRSpVdmvADYVbZk ROKd6ywAzBg484ssFcn8mhI= X-Google-Smtp-Source: AA0mqf6Ys3bcskGANthyVZNNz9YvhOZrI6VSoFH21Z+t3ZqaDk8YnWysyA8v1PERN7uLGtrV45Yorg== X-Received: by 2002:a1c:f616:0:b0:3cf:b1c2:c911 with SMTP id w22-20020a1cf616000000b003cfb1c2c911mr11754892wmc.16.1669189378361; Tue, 22 Nov 2022 23:42:58 -0800 (PST) Original-Received: from [192.168.178.21] (pd9e36ab4.dip0.t-ipconnect.de. [217.227.106.180]) by smtp.gmail.com with ESMTPSA id fn8-20020a05600c688800b003cfd42821dasm1349921wmb.3.2022.11.22.23.42.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Nov 2022 23:42:57 -0800 (PST) Content-Language: en-US In-Reply-To: <871qpubx1p.fsf@rfc20.org> Received-SPF: pass client-ip=2a00:1450:4864:20::332; envelope-from=gerd.moellmann@gmail.com; helo=mail-wm1-x332.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, NICE_REPLY_A=-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:300381 Archived-At: On 22.11.22 20:37, Matt Armstrong wrote: > Gerd Möllmann 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. Hm, I must admit that I don't see an ambiguity here. Maybe you are thinking of something like the following? Assume packages A and B, A using B and containing a defun for f. Next, B is modified to export B:f, which A inherits. A is recompiled, and the compiler sees "(defun f () 42)". In this case, the 'f' refers to B:f, but unambiguously. If that's what you are thinking about, yes that's a known problem, which is, in most, if not all, CL implementations, solved with "package locks". In CLisp: https://clisp.sourceforge.io/impnotes/pack-lock.html > > 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. But that's not unique to adding symbols. The same is potentially true for all sorts of API changes. >> 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'. Here we have different opinions. I see no need to forbid use-package. Imagine a CL without use-package, being in some package. I don't want to write cl:car everywhere. What for? > > 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). Does Python have internal symbols? > 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. More power to you :-).