A namespace implementation for Emacs Lisp

by pmoriarty • 12 years ago

67 11 12 years ago

josteink• 12 years ago

I've seen this before and it's definitely a nice stop-gap solution to a well known and common problem.

However the existence of something like this IMO really shows that a feature like this should be Emacs (25?) itself, at the core, preferably without creating indentation issues by leaving your entire module a nesten s-exp.

In an ideal world something like (ns 'my-package) statement at the start of your module should be enough.

In a less ideal world, that simple solution will cause compatibility problems when you want packages to work for both Emacs pre-ns and Emacs post-ns.

How to get that done properly is a genuinely hard question. Any suggestions? Any takers?

rson• 12 years ago

For what it's worth, this macro doesn't cause the indentation issue due to how it's defined[1]. It does, however, leave the extra sexp around your package.

From my experimentation the package worked quite well for the most part but I ended up not using it in the end.

1: https://github.com/Bruce-Connor/names/blob/master/names.el#L...

lukego• 12 years ago

Isn't it amazing how well Emacs development scaled without basic features like namespaces and lexical scope?

These days I find myself more inclined to try and borrow ideas from Emacs Lisp than to retrofit modern ideas back onto it.

How important can those features really be if their absence has only been a nuisance during decades of development?

oblio• 12 years ago

Are you sure they were only a nuisance?

jarcane• 12 years ago

There is still production code, in quantity, in COBOL.

I would hesitate to take a whole lot from that other than 'Given sufficient determination, almost anything can be written in any language that offers a minimal level of completeness.'

aardvark179• 12 years ago

Dynamic scope (the expectation of it, and the patterns of programming that it encourages) become more than just a nuisance when you try to separate work into tasks that can be handled by any form of task pool. In general any form of concurrency combined with dynamic scoping is at best painful, and at worst a disaster, and working round those issues introduces considerable runtime inefficiency.

hollerith2• 12 years ago

That is true, but IMHO it is probably irrelevant to Emacs because adding concurrency to Emacs is probably a bad idea.

Firefox of course has concurrency, and IMHO it makes Firefox a lot "glitchier" than Emacs is (or Firefox would be if it did not have concurrency). Several times a day, Firefox goes unresponsive for a few seconds. That does not make Firefox unusable or unsatisfactory, but not being able to rely on a timely response from Firefox 100% of the time to a keypress or pointing-device input really does seem to change the way I use Firefox.

Anyone with experience with math, even with doing multiplications and divisions in one's head, can see that how much complexity the mind can handle is dependent on how quickly one can execute sub-tasks. That is an example of the general principle getting fast -- reliably fast -- at the sub-tasks increases the complexity of the tasks one can handle (and of course it is the reliable quickness of small sub-tasks that glitchiness of the user experience interferes with).

Those without experience with Emacs or Vim (which I am guessing is like Emacs in being 100% responsive) can get an idea of what I mean by comparing their experience in using Firefox or Google Chrome with their experience of using a terminal-emulation app and a Unix shell: although some shell command lines do take a while to produce a response from the system, most of the time, the user can predict when a delay will occur (e.g., a `find` over the whole directory hierarchy) and even when the user is surprised by the presence of a delay, in retrospect there is always a reasonable explanation for the delay if the user is willing to think through and learn about enough details about the system.

(Yes, I realize that there are some applications that some people would like to write in Emacs Lisp that simply cannot be written without concurrency without blocking Emacs for many many seconds at a time. I am skeptical that being able to write those application in Emacs Lisp is worth the cost in complexity and in glitchiness of the user experience.)

The above is a simplification: in reality, glitches do happen in Emacs and in an interactive Unix shell, but I am almost sure that the cause of those glitches is in the underlying OS, not in the Emacs or the Unix-shell process.

lispm2• 12 years ago

Well, GNU Emacs came after other Emacs implementations which had namespaces, threads and closures. For example Zmacs on the Lisp Machine had all that. It was written in Lisp Machine Lisp (aka Zetalisp). Richard Stallman had used it and contributed to it. So GNU Emacs would borrow from ideas older than its implementation.

skywhopper• 12 years ago

Personally, in terms of just convention, I've taken to the style of using "packagename/" as a function-name prefix in my own Elisp code. Since the hyphen is the conventional between-word character for function names, it sets it off much better visually.

But more specificially, I don't really like the idea of adding this "feature". I don't mind the extra characters in the function names. Verbosity and clarity are good things. So long as package maintainers follow naming conventions, that's far preferable to trying to read code that may or may not have apparent duplicate function names.

A namespace implementation for Emacs Lisp

Related Stories