46

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?
new Q Open Wid
  • 185
  • 1
  • 12
Dan
  • 32,584
  • 6
  • 98
  • 168
  • 7
    You could have a look at this: https://github.com/Bruce-Connor/names It appears to be a backwards-compatible (with the current manual way of separating names) implementation of automatic namespaces. (And I'm 99% sure I've seen another such library, allowing the developer to export a subset of functions with namespaces, mentioned recently on some emacs blog, but I couldn't find it back). – T. Verron Oct 27 '14 at 13:30
  • 4
    I second you should have a look at the link above. It is a very recent (released last month) and very robust namespace macro. I'm still working out a few kinks in terms of compatibility with tools like edebug, but the package works. Answering your question is a really long essay (the technical barriers I faced were many) but I'll try to put it into blog posts over the next weeks. – Malabarba Oct 27 '14 at 14:02
  • 1
    I guess namespaces mean different things. I would have said emacs has several namespaces: One for variables, another for functions and macros, another for faces, and for themes, and … – Harald Hanche-Olsen Oct 27 '14 at 20:11
  • 2
    @HaraldHanche-Olsen you can certainly say that. In that context he's asking why there aren't per-package namespaces. – Malabarba Oct 27 '14 at 23:41

2 Answers2

33

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:

StackExchanger
  • 133
  • 6
Malabarba
  • 22,878
  • 6
  • 78
  • 163
  • 1
    Thanks -- that was a very informative take on the issue. I'm curious about your last point re: your `names` solution. I wonder if there's any reason to suspect that an organic, built-in solution is coming in the not-too-distant future, or if we should just adopt the built-*on* solution you've provided. – Dan Oct 28 '14 at 18:48
  • 2
    @Dan [Yes, there is.](http://www.reddit.com/r/emacs/comments/2khl98/big_things_to_expect_from_emacs_25/clm18gn). That said, there's no reason not to adopt *Names* in the meantime. It's fully compatible with Emacs' conventions, so any package using *Names* is free to stop using *Names* at any time, and the user won't know a thing. – Malabarba Oct 28 '14 at 21:08
  • 1
    You really should add `nameless` to this list :) It's a brilliant idea, and it solves the problem very neatly. – Clément Jun 13 '16 at 02:19
  • @Clement: it's done. Personally, I like that solution the best because it is so lightweight. – StackExchanger Oct 22 '22 at 21:57
22

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.

Stefan
  • 26,154
  • 3
  • 46
  • 84
  • I think that could be easily 'fixed' by creating aliases for the most used common functions (or all of them, maybe) – Jesse Jul 18 '15 at 21:02
  • 4
    The need to "grep" shows up usually while developping a package, whre you need to know where a variable/function might be used in other packages, so it can apply to any arbitrary variable/function, rather than only for specific important ones. For this reason, adding a few aliases will make no difference. Another reason why mit won't help, is that adding an alias won't help you find the uses that don't use this alias. – Stefan Jul 19 '15 at 23:34