4 ms·

As I've been learning more Emacs Lisp and Common Lisp, I've found that they're really quite similar. So I've been wondering why Emacs wasn't written in Common

by acdw 5y ago

As I've been learning more Emacs Lisp and Common Lisp, I've found that they're really quite similar. So I've been wondering why Emacs wasn't written in Common Lisp. Of course, I think the answer to that one is the age of Emacs -- it was around before CL? -- but this project will be one that I check in on periodically, for sure.

jhgb 5y ago
Common Lisp didn't exist in a useful state at that time. Furthermore was probably too large for this application at that time.
- agumonkey 5y ago
  Also a bit controversial.
iib 5y ago
This is the story [1], told by Stallman. But yes, basically because Common Lisp was too big. That is also the reason GNU uses Scheme as a language for extensions. [1] http://www.gnu.org/gnu/rms-lisp.html http://www.gnu.org/gnu/rms-lisp.html
- dan-robertson 5y ago
  Common Lisp was considered too big in its day but compared to many modern languages it is quite small (only 25 or so special forms, most of which are rarely used; few built in types). I think the problem was that there was still too much of a separation between the language itself and user written functions. Because so much of the language cares about object identity, one couldn’t write a portable hash table oneself. Making a data structure like a search tree becomes hard because there isn’t a good way to sort arbitrary objects of arbitrary type or embed a specific sorting function and type check. CLOS is both massive and poorly integrated. The language is full of features that are old (rplca), hard to compile (&rest, adjustable arrays with fill pointers whose data is from another array at an offset), inextensible (loop, +), half-baked (types), or difficult (pathnames). But it also misses many features (eg threads). Without a refreshed standard it is hard for the language to move forward while code remains portable. In some ways I think of Julia and clojure as successors. Julia has types and multimethods working very well together but drops method combinations, pervasive mutability, lists, symbols, and syntax for good macros. Clojure keeps the macro-happy syntax and symbols, bins the mutability, and makes the data structures more compatible, functional and efficient. Obviously this doesn’t have so much relevance to emacs past or present.
nerdponx 5y ago
I'd be curious about a Racket implementation. I know Racket is supposed to be a research and teaching language, but in several respects it seems to be a better Common Lisp than Common Lisp itself.
- dreamcompiler 5y ago
  That might have become more true recently because of the Racket-on-Chez compiler, but until then Racket was in most cases slower than Common Lisp because it wasn't AOT compiled to the metal, which Common Lisp is. I also like CLOS (the Common Lisp object system) better than the object systems available in Racket, as well as Common Lisp's macro system. But that's just personal preference. The existence of Typed Racket is pushing me to explore Racket more.
  - gmfawcett 5y ago
    > it wasn't AOT compiled to the metal, which Common Lisp is. It's required that a CL implementation supports compilation, but compiling to machine code isn't required. e.g., Clisp has a bytecode compiler. - https://en.wikipedia.org/wiki/Common_Lisp#Compiler_and_interpreter https://en.wikipedia.org/wiki/Common_Lisp#Compiler_and_inter... - https://clisp.sourceforge.io/impnotes.html#bytecode https://clisp.sourceforge.io/impnotes.html#bytecode
    - lispm 5y ago
      Though they experimented with a native code JIT...
- mark_l_watson 5y ago
  That would be nice, for sure. At least the Racket IDE editor supports some Emacs key bindings.
- vindarel 5y ago
  Here are some lispers' impressions: https://gist.github.com/vindarel/c1ef5e043773921e3b11d8f4fe1ca7ac https://gist.github.com/vindarel/c1ef5e043773921e3b11d8f4fe1... Racket seems to miss at least two big points: the interactivity/the debugger and the condition system.
ska 5y ago
emacs in various forms definitely predates CL; but I suspect around the time CL was ratified (84?) any discussions about a re implementation would have focused on the size of CL implementations being unacceptable for inclusion in an editor...
- lispm 5y ago
  subsets of Common Lisp existed early on
  - ska 5y ago
    Sure, and lots of lisps existed in the 15 years or so before CL. The ones that looked anything like CL were pretty heavy. I imagine the decision to write elisp at all in the first place was made by people pretty familiar with what existed at the time, and why it wasn't a good fit for them....
    - lispm 5y ago
      xlisp for example started small in 1983 and over time added some CL features. It was also used by Autodesk as the base of Autolisp for Autocad on a zillion PCs... > The ones that looked anything like CL were pretty heavy yeah, Coral Lisp needed 1 MB RAM on a 68k Mac. Morphed into a Common Lisp then. mulisp in 85 supported 0.5MB RAM on a PC. It had some CL compatibility.
    - rjsw 5y ago
      Franz Lisp could probably have run MacLisp Emacs.

by acdw 5y ago

jhgb 5y ago

Common Lisp didn't exist in a useful state at that time. Furthermore was probably too large for this application at that time.

agumonkey 5y ago
Also a bit controversial.

iib 5y ago

This is the story [1], told by Stallman. But yes, basically because Common Lisp was too big. That is also the reason GNU uses Scheme as a language for extensions. [1] http://www.gnu.org/gnu/rms-lisp.html http://www.gnu.org/gnu/rms-lisp.html

dan-robertson 5y ago
Common Lisp was considered too big in its day but compared to many modern languages it is quite small (only 25 or so special forms, most of which are rarely used; few built in types). I think the problem was that there was still too much of a separation between the language itself and user written functions. Because so much of the language cares about object identity, one couldn’t write a portable hash table oneself. Making a data structure like a search tree becomes hard because there isn’t a good way to sort arbitrary objects of arbitrary type or embed a specific sorting function and type check. CLOS is both massive and poorly integrated. The language is full of features that are old (rplca), hard to compile (&rest, adjustable arrays with fill pointers whose data is from another array at an offset), inextensible (loop, +), half-baked (types), or difficult (pathnames). But it also misses many features (eg threads). Without a refreshed standard it is hard for the language to move forward while code remains portable. In some ways I think of Julia and clojure as successors. Julia has types and multimethods working very well together but drops method combinations, pervasive mutability, lists, symbols, and syntax for good macros. Clojure keeps the macro-happy syntax and symbols, bins the mutability, and makes the data structures more compatible, functional and efficient. Obviously this doesn’t have so much relevance to emacs past or present.

nerdponx 5y ago

I'd be curious about a Racket implementation. I know Racket is supposed to be a research and teaching language, but in several respects it seems to be a better Common Lisp than Common Lisp itself.

dreamcompiler 5y ago
That might have become more true recently because of the Racket-on-Chez compiler, but until then Racket was in most cases slower than Common Lisp because it wasn't AOT compiled to the metal, which Common Lisp is. I also like CLOS (the Common Lisp object system) better than the object systems available in Racket, as well as Common Lisp's macro system. But that's just personal preference. The existence of Typed Racket is pushing me to explore Racket more.
- gmfawcett 5y ago
  > it wasn't AOT compiled to the metal, which Common Lisp is. It's required that a CL implementation supports compilation, but compiling to machine code isn't required. e.g., Clisp has a bytecode compiler. - https://en.wikipedia.org/wiki/Common_Lisp#Compiler_and_interpreter https://en.wikipedia.org/wiki/Common_Lisp#Compiler_and_inter... - https://clisp.sourceforge.io/impnotes.html#bytecode https://clisp.sourceforge.io/impnotes.html#bytecode
  - lispm 5y ago
    Though they experimented with a native code JIT...
mark_l_watson 5y ago
That would be nice, for sure. At least the Racket IDE editor supports some Emacs key bindings.
vindarel 5y ago
Here are some lispers' impressions: https://gist.github.com/vindarel/c1ef5e043773921e3b11d8f4fe1ca7ac https://gist.github.com/vindarel/c1ef5e043773921e3b11d8f4fe1... Racket seems to miss at least two big points: the interactivity/the debugger and the condition system.

ska 5y ago

emacs in various forms definitely predates CL; but I suspect around the time CL was ratified (84?) any discussions about a re implementation would have focused on the size of CL implementations being unacceptable for inclusion in an editor...

lispm 5y ago
subsets of Common Lisp existed early on
- ska 5y ago
  Sure, and lots of lisps existed in the 15 years or so before CL. The ones that looked anything like CL were pretty heavy. I imagine the decision to write elisp at all in the first place was made by people pretty familiar with what existed at the time, and why it wasn't a good fit for them....
  - lispm 5y ago
    xlisp for example started small in 1983 and over time added some CL features. It was also used by Autodesk as the base of Autolisp for Autocad on a zillion PCs... > The ones that looked anything like CL were pretty heavy yeah, Coral Lisp needed 1 MB RAM on a 68k Mac. Morphed into a Common Lisp then. mulisp in 85 supported 0.5MB RAM on a PC. It had some CL compatibility.
  - rjsw 5y ago
    Franz Lisp could probably have run MacLisp Emacs.