3 ms·
Definitely this. It just feels so natural to have all those functions in the same scope without dealing with modules, hierarchies or something involving both.
by emacsuser31 5y ago
Definitely this. It just feels so natural to have all those functions in the same scope without dealing with modules, hierarchies or something involving both.
I also believe that none of the languages with module hierarchies are suitable for some kind of REPL driven development. You can't just dump all of your program into the REPL and expect it to work. You need globally unique names for these. And I believe this is a must for a language that is running inside an editor.
- Jtsummers 5y agoCommon Lisp has packages and is certainly as suited for REPL-driven work as Emacs Lisp. I'm not convinced that a lack of at least a flat set of namespaces (like CL) wouldn't be an improvement on Emacs' "prefix everything" approach. Perhaps more important to Emacs Lisp is that everything is open. If you took just something like CL's packages but had every symbol exported by default you'd get something that's not a far cry from Emacs' present approach but with better code organization capabilities.
- dan-robertson 5y agoBut of course Common Lisp has similar qualities: one can still write unexported symbols, there is just the worry that the internals may change. I think the important qualities are that the configuration is typically done with global and buffer-local variables (a super-lightweight and extensible solution to the obvious problem of per-buffer state) with simple types (alists, hooks, etc). One issue with Common Lisp style packages is that they may interfere with lazy loading. In emacs you can setq a symbol before the package loads and then the defvar will not change the value, but in CL you cannot read the symbol until the package is defined so things like eval-after-load (ie lazy load then configure) suck.