3 ms·

Why is the core of Emacs still written in C? Is it just fear of trying to rewrite it from the ground up in Lisp, or is there something fundamental to the archit

Why is the core of Emacs still written in C? Is it just fear of trying to rewrite it from the ground up in Lisp, or is there something fundamental to the architecture that makes Lisp unsuitable?

Jtsummers 10y ago
History, it's been in continuous development for over three decades now. And, being open source, a port of the C portions to a new language would require developer effort that doesn't always appear on demand. Also portability. GNU Emacs supports a fair number of platforms and, consequently, has a lot of things included in it for different platforms, different presentation layers (GUI, CLI). It's not a small task to support the variety of environments that it presently does with a novel implementation. And then there's the bootstrap issue. Emacs lisp isn't compiled to a standard binary executable format, they use their own bytecode. So even if you did port more portions that are in C to elisp, you still need an environment to run that elisp in, and the problem that the dumper file solves is actually made worse, more elisp needs to be loaded and executed before you get into a functional editor. There is work to port elisp to run on type of Guile, but it's not done yet. Lacking developer resources and other things. Like the issue of losing support for various environments, it also doesn't 100% support the existing base of elisp packages out there, which is a deal breaker for many people.
dima55 10y ago
Because C compiles to machine code and computers only understand machine code.
AceJohnny2 10y ago
Because that's the part that needs to interact with the OS at a low-level. Think of it as the "OS bindings" if you will. C is the lowest-common-denominator to do that. Edit: I'm wrong, see avar's response below. It looks like it's for performance reasons.
- avar 10y ago
  Relatively speaking this really couldn't be further from the truth. There's plenty of codebases that implement some programming language and only use C bindings for truly low-level primitives, such as external library calls, memory allocation etc, leaving any substantial logic that's built on top of those OS primitives to a higher level language. Emacs is not such a codebase, most of the C code by volume is things that could perfectly well be implemented in Emacs Lisp itself, but aren't because Emacs Lisp is relatively slow. So while it's fine for "scripting" Emacs itself, things like regexes, anything that has to do with low-level character handling, most of the GUI layout of Emacs itself (i.e. the buffer logic etc, not actually calling ncurses or X) etc. is written in C. Just browse through the C files in src/, most of this clearly has nothing to do with interacting with low-level OS primitives: http://git.savannah.gnu.org/cgit/emacs.git/tree/src http://git.savannah.gnu.org/cgit/emacs.git/tree/src
  - lispm 10y ago
    > most of the C code by volume is things that could perfectly well be implemented in Emacs Lisp itself, A substantial part of the GNU Emacs core is written in C: the byte code virtual machine, the core Emacs Lisp language implementation, loading/saving images, memory management, ... That's not implementable in the current Lisp architecture (which additionally is single threaded). If we want to move more of the language implementation in Lisp, that's possible - see implementations like SBCL or Clozure CL. Porting/maintaining these seems more difficult. But then you can implement regexes and other stuff in Lisp.
  - torrent-of-ions 10y ago
    Yes. Basically the Emacs "C bit", is not just a Lisp like Clisp or SBCL, it also has a load of text editor code. Have a "CLmacs", ie. an emacs written in Common Lisp, is something a lot of people would really like. The problem, of course, is the vast amount of elisp that we currently use in our editors.
    - kazinator 10y ago
      You'd think that an Elisp implementation plus the necessary API's could be provided to make a good bulk of that code work.

Why is the core of Emacs still written in C? Is it just fear of trying to rewrite it from the ground up in Lisp, or is there something fundamental to the architecture that makes Lisp unsuitable?

Jtsummers 10y ago

History, it's been in continuous development for over three decades now. And, being open source, a port of the C portions to a new language would require developer effort that doesn't always appear on demand. Also portability. GNU Emacs supports a fair number of platforms and, consequently, has a lot of things included in it for different platforms, different presentation layers (GUI, CLI). It's not a small task to support the variety of environments that it presently does with a novel implementation. And then there's the bootstrap issue. Emacs lisp isn't compiled to a standard binary executable format, they use their own bytecode. So even if you did port more portions that are in C to elisp, you still need an environment to run that elisp in, and the problem that the dumper file solves is actually made worse, more elisp needs to be loaded and executed before you get into a functional editor. There is work to port elisp to run on type of Guile, but it's not done yet. Lacking developer resources and other things. Like the issue of losing support for various environments, it also doesn't 100% support the existing base of elisp packages out there, which is a deal breaker for many people.

dima55 10y ago

Because C compiles to machine code and computers only understand machine code.

AceJohnny2 10y ago

Because that's the part that needs to interact with the OS at a low-level. Think of it as the "OS bindings" if you will. C is the lowest-common-denominator to do that. Edit: I'm wrong, see avar's response below. It looks like it's for performance reasons.

avar 10y ago
Relatively speaking this really couldn't be further from the truth. There's plenty of codebases that implement some programming language and only use C bindings for truly low-level primitives, such as external library calls, memory allocation etc, leaving any substantial logic that's built on top of those OS primitives to a higher level language. Emacs is not such a codebase, most of the C code by volume is things that could perfectly well be implemented in Emacs Lisp itself, but aren't because Emacs Lisp is relatively slow. So while it's fine for "scripting" Emacs itself, things like regexes, anything that has to do with low-level character handling, most of the GUI layout of Emacs itself (i.e. the buffer logic etc, not actually calling ncurses or X) etc. is written in C. Just browse through the C files in src/, most of this clearly has nothing to do with interacting with low-level OS primitives: http://git.savannah.gnu.org/cgit/emacs.git/tree/src http://git.savannah.gnu.org/cgit/emacs.git/tree/src
- lispm 10y ago
  > most of the C code by volume is things that could perfectly well be implemented in Emacs Lisp itself, A substantial part of the GNU Emacs core is written in C: the byte code virtual machine, the core Emacs Lisp language implementation, loading/saving images, memory management, ... That's not implementable in the current Lisp architecture (which additionally is single threaded). If we want to move more of the language implementation in Lisp, that's possible - see implementations like SBCL or Clozure CL. Porting/maintaining these seems more difficult. But then you can implement regexes and other stuff in Lisp.
- torrent-of-ions 10y ago
  Yes. Basically the Emacs "C bit", is not just a Lisp like Clisp or SBCL, it also has a load of text editor code. Have a "CLmacs", ie. an emacs written in Common Lisp, is something a lot of people would really like. The problem, of course, is the vast amount of elisp that we currently use in our editors.
  - kazinator 10y ago
    You'd think that an Elisp implementation plus the necessary API's could be provided to make a good bulk of that code work.