[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help sought understanding shorthands wrt modules/packages

From: Gerd Möllmann
Subject: Re: Help sought understanding shorthands wrt modules/packages
Date: Wed, 23 Nov 2022 08:42:56 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.5.0

On 22.11.22 20:37, Matt Armstrong wrote:
Gerd Möllmann <gerd.moellmann@gmail.com> 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:


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

More power to you :-).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]