Why does elisp not have namespaces?

Question

Q: Why does elisp not have namespaces, and how could we get them?

Elisp does not have namespaces other than the global one, which has led to the coding convention of prefixing all global functions, variables, and constants with a unique prefix.

Aside from the annoyance factor, it also strikes me as a simmering issue given 1) the ever-expanding number of great libraries and packages, and 2) the continued existence of legacy functions and variables that either don't respect the prefix convention, or are sufficiently idiosyncratic that there isn't really a good prefix option they could use. It also means that periodic attempts to rationalize older code (as with the transition from cl to cl-lib) is a non-trivial amount of work. (Although I'm glad for the clean-up, I still shed a tear every time I type something like cl-find).

I went poking around to see if I could find out why elisp still doesn't have namespaces after a few decades of use, but was a little surprised at the modest harvest. The wiki page on namespaces is quite short. Nic Ferrier has a slightly longer treatment of the issue, and there's a fairly recent thread on emacs-devel on it as well. There's an old Stack Overflow thread from 2010 that discusses the possibility of using macros to implement namespaces; another example of the macro approach can be found here. There are at least a couple of implementations (here and here, with a description of the latter here) out there, but they haven't seen much activity for a couple of years, and I've not run across any libraries that use them.

I presume that, if adding namespaces were easy, it would already be done. So:

• What are the technical barriers to adding namespaces to elisp?
• Would adding namespaces break a lot of existing code?
• Is this functionality something that needs to be organic to elisp (changes to the interpreter itself), or could it really be built on top via macros?

Answer 1

Why no Namespaces?

Because it's complicated, and no one has considered it urgent enough to take the full plunge yet. This has been discussed in the dev list before (more times than one), and there have been promises of fixing this after the move to git.

In the meantime, I wrote a solution of my own (see below for a list of options).

What are the technical barriers?

Just out of the door you have 3 large obstacles, which you need to surpass so that namespaces even have a chance of working on a current Emacs:

• You need to change how symbols are interned (this is the easy part).
• The byte-compiler needs to understand namespaces.
• The autoload generation used by package.el needs to understand namespaces.

Patching these 3 things to work with however you come to implement namespaces isn't trivial. If you're dedicated only to the most recent Emacs version it's certainly doable. If you're looking to write some sort of package which also supports previous versions (like the entire 24 family), it turns into one hell of a challenge.

Beyond that, there are tons of other optional obstacles. Elisp is great because of all the power in the tools available to you and ALL of these would need to be patched to work with namespaces. Amongst the most important are:

• edebug
• eval-defun
• eval-last-sexp
• slime

Would it break a lot of existing code?

Not if you do it right.

Is this something that needs to be organic, or could it really be built on top via macros?

Ideally it would be organic, that's what is usually discussed when it comes up in the dev list. But it can be made good enough while being built on top.
Here are a few examples of this, taken from this list:

• Names
• with-namespace
• Codex
• Fakespace
• elisp-namespaces
• nameless

Answer 2

Last time this was discussed on emacs-devel, the discussion stopped when people like Lars pointed out that they like to be able to M-x grep for something. Adding namespaces to Elisp shouldn't be too hard, but getting all the familiar tools to handle them right is another issue.