Re: Help sought understanding shorthands wrt modules/packages

[Gerd Möllmann]

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:

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 :-).