A namespace implementation for Emacs Lisp(github.com)
github.com
A namespace implementation for Emacs Lisp
https://github.com/Bruce-Connor/names
3 comments
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?
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?
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...
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...
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?
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?
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.
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.
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.
> Several times a day, Firefox goes unresponsive for a few seconds.
This is caused by concurrency?
This is caused by concurrency?
That is my best guess. I could be wrong. Should people refrain from publishing their guesses on HN?
None of the programs I have used that lack threads, including lynx, have this kind of glitchiness. (Also, I think early versions of X lacked threads and at least when paired with certain video cards, were free of glitchiness -- or more precisely, a user could learn to operate X in such a way as to avoid glitchiness.)
In particular, my guess is that although it is theoretically possible to write huge multi-threaded programs that do not exhibit glitchiness, in reality it is too hard for even very skilled human programmers to do it, and that is why Firefox has the glitchiness property.
I am willing to listen to arguments to the contrary.
P.S. I would have supposed that those who disagree with my conclusion would simply deny that Firefox is glitchier than Emacs or would simply conclude that the difference in glitchiness is irrelevant. Do you agree with me that it is glitchier and that the glitchiness matters?
(Again, I realize the glitches are rare -- maybe only a few a day. They do affect my experience of the app, though.)
None of the programs I have used that lack threads, including lynx, have this kind of glitchiness. (Also, I think early versions of X lacked threads and at least when paired with certain video cards, were free of glitchiness -- or more precisely, a user could learn to operate X in such a way as to avoid glitchiness.)
In particular, my guess is that although it is theoretically possible to write huge multi-threaded programs that do not exhibit glitchiness, in reality it is too hard for even very skilled human programmers to do it, and that is why Firefox has the glitchiness property.
I am willing to listen to arguments to the contrary.
P.S. I would have supposed that those who disagree with my conclusion would simply deny that Firefox is glitchier than Emacs or would simply conclude that the difference in glitchiness is irrelevant. Do you agree with me that it is glitchier and that the glitchiness matters?
(Again, I realize the glitches are rare -- maybe only a few a day. They do affect my experience of the app, though.)
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.
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.'
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.'
Are you sure they were only a nuisance?
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.