Re: Proper namespaces in Elisp

[Vladimir Sedach]

João Távora <address@hidden> writes:
> It's you who presented a dependency problem, remember?

This is a namespace problem that shows up in, and breaks, dependency
management. Trying to solve it at the step of dependency management
is too late.

> Let me get this straight: people there recommended you
> should use :USE for library packages you depend on?

They recommend the opposite, because a lot of Common Lisp libraries
do in fact :USE all of their dependencies, and this has resulted in
real problems. This was not a widely recognized problem 10 years ago.
I would appreciate it if you stop replying to my suggestion with
sarcastic misinterpretations, and discuss the issue with other
programmers in #lisp

> No there aren't, short of _not_ providing namespace merging.
> There's no point in explaining this again, I think.

I don't know why you are claiming this, considering that you
previously suggested an excellent solution.

If you look at what a best-practices Common Lisp package definition
with package-local nicknames would look like, it would :USE only the
"COMMON-LISP" package, and references other packages with local
nicknames.

Restricting the :USE list to 0 or 1 packages, and references to
symbols in other packages to package local nicknames, would be a
radical simplification of the Common Lisp package system without loss
of generality, and would solve many problems. In addition to avoiding
the unintended re-definition problem, this avoids the problem of
clashes in exported symbol names between packages - a problem which
R6RS also suffers from, but which is far less likely to occur than
unintended re-definition. You no longer need any of the import,
shadow, global nicknames, or conflict resolution facilities.

So you see, by engaging in constructive exploration of the design
space, you helped to make what I think is a major contribution to
namespace system design and to Common Lisp. I am going to start using
this pattern in my own code, and I hope any future Lisp that wants to
adopt a Common Lisp-style package system uses this modified design.

Unfortunately, this still relies on the reader to resolve namespaces,
so might not work for Elisp.

Which brings me to an important realization that is obvious in
hindsight:

In fact, most Common Lisp implementations already follow the R6RS
solution to the unintended re-definition problem by special-casing
the COMMON-LISP package to be locked, exactly to address the
unintended re-definition problem. And the COMMON-LISP package has not
changed since 1994.

This is not the case for Elisp.

The unintended re-definition problem is not a problem only for
third-party packages as I had previously thought. If left unaddressed
this is going to be a major problem for all Elisp code. You think you
would be safe defining a short name for something in your local
namespace, then a new function with the same name is added to Elisp
in the next Emacs release, and now you have broken
backwards-compatibility with what should be a backwards-compatible
change. This is a lot worse than the current status quo of not having
a namespace system.

One way to address this issue is to version Elisp namespaces to major
Emacs versions: elisp29, elisp30, etc. This would enhance both
backward compatibility (you can fix problematic behavior in Elisp
functions without breaking packages that depend on that behavior;
package maintainers would have more time to make changes for new
Emacs versions), and ongoing Emacs development (besides fixing
problematic functions, aliases and deprecated functions can be
dropped from the current version namespace so that new Elisp user
code does not unintentionally continue to use them, and moved to
separate files to reduce clutter).

I think this is a much better reason for having a namespace system
than "I don't want to use autocomplete to type long symbol names."

> I've worked for 15 years day to day with experienced Common Lisp
> programmers. You can add my (and I think their) recommendation to
> the list: Don't use :USE for packages outside your control, else feel
> free to use it. Think of :USE as :MERGE.

I am not here to tell Common Lisp programmers what to do. What I
would like is for any Elisp namespacing system to avoid known
problems. At the very least, if whole-namespace importing is
provided, it should come with a very loud disclaimer not to use it
with third-party packages. But that would mean the facility would be
very seldom used in good Elisp code, and abused in bad Elisp code (of
which there seems to be no shortage written every day), so why bother
having it and its many downsides when better alternatives are
available?

--
Vladimir Sedach
Software engineering services in Los Angeles https://oneofus.la