Re: Help sought understanding shorthands wrt modules/packages

[Matt Armstrong <matt@rfc20.org>]

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.

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.