Re: Proper namespaces in Elisp

[Vladimir Sedach]

Daniel Colascione <address@hidden> writes:
> So there are three basic operations we can support: in Python syntax,
> 1) from PKG import * (exposing PKG.foo as foo), 2) import PKG as p
> (exposing PKG.foo as p.foo) and 3), from PKG import foo (exposing
> PKG.foo as foo).  CL supports all three. I'm most interested in
> supporting #2, since that's closest to existing use. The lexspace
> prototype posted earlier today supports #3 and #1 (the latter via
> lexspace inheritance) only, but I think we should do #2 instead, and
> I think we can do it without runtime overhead.

Before I write anything else, I have to call attention to a fact you
might already be aware of: Python cannot do code re-loading reliably,
because depending on which of these 3 ways a function is imported,
the new definition might or might not be seen.

This is a really good example of the way that namespace systems can
have unintended consequences, and why we have to be careful designing
one for Elisp.

#3 is ok, because that way you know exactly what you are importing,
and will not get any surprises if PKG exports another definition
later.

Most use cases want a single #1 to pull in the language that you are
working in (in Common Lisp, this would be the "COMMON-LISP" package).

As I pointed out in another sub-thread, this can be used to advantage
if you version Elisp namespaces to major Emacs versions (elisp29,
elisp30, etc.). It is a lot easier to support backwards compatibility
and make major changes to Emacs that way.

The only problem is retrofitting this on top of the global namespace.
The global namespace is going to have to be a fallback for all symbol
lookups. Existing libraries also need to have their declared exports
put into the global namespace with their chosen package prefix and
appropriate autoloads, to be compatible with packages that do not use
namespaces (advice/redefinition is going to have to do the
appropriate thing in both places, and dynamic bindings have to be
shared!). Modifying internal functions is already a gamble on
updates, so I think it is ok to tell people "you need to access this
internal function with a namespace qualifier because the package now
uses namespaces."

The reason #1 becomes a problem is if you do it two or more times.
This is akin to "namespace multiple inheritance." This is different
from multiple inheritance in OO because it is not transitive (you do
not want to import the dependencies of the package you are
importing!).

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