6 ms·

I've always wished Emacs would have been written in Common Lisp. It would already support this, and it's all around just a better language (IMO). There's Clim

I've always wished Emacs would have been written in Common Lisp. It would already support this, and it's all around just a better language (IMO). There's Climacs, but it's so far behind...

dmortin 7y ago
Couldn't emacs lisp be simply ported to work on the JVM? Then emacs would get a battle tested virtual machine, and the emacs devs could focus on the editor, instead of dealing with VM speed.
- sansnomme 7y ago
  Keep your fingers crossed for Remacs. Cranelift can probably give it a magnitude increase of speed if things go well. They are about halfway through, give them a hand! https://github.com/remacs/remacs/wiki/Progress https://github.com/remacs/remacs/wiki/Progress If every C/C++ programmer/member of the Rust Evangelism Strikeforce here on HN help port a function, we would have a Rust Emacs in under a month. C'mon everyone, the remaining code is pretty simple and straightforward: https://github.com/remacs/remacs/tree/master/src https://github.com/remacs/remacs/tree/master/src Just mechanical translation to Rust. ONE FINAL SPRINT, and we will be done. The hard work of setting up the tooling and macros are already finished. Many here are happy to moan and complain about Electron infecting everything. Channel your anger into this project! Just help port one function, this isn't even leet coding level of difficulty. If you believe yourself to be a great software engineer, then lend a hand. Don't want Electron editors like VS Code and Atom to be the only game in town 5 years from now? Help translate a couple lines now. It's literally a single docker pull to setup the dev env. Low hanging fruits: https://github.com/remacs/remacs/blob/master/src/indent.c https://github.com/remacs/remacs/blob/master/src/indent.c Tl;Dr: like Leftpad but more ugly.
  - sedachv 7y ago
    None of these proposals are going to address the main problem: most Emacs modes depend on a lot of regular expressions for syntax highlighting and many other things. Regular expressions are slow; it is a computational complexity problem. That is, for example, the main problem behind long lines being slow (and why they are not so slow in fundamental-mode). Now that Emacs has multi-threading, pervasive regular expressions are the last big thing that is responsible for noticeable performance issues.
    - sansnomme 7y ago
      What sort of Regex are they using? The garden variety can be compiled to DFAs (O(n)) which a modern computer should have no issues handling. Further optimizations
      - rcthompson 7y ago
        I believe Emacs has its own regular expression syntax that doesn't correspond exactly to either POSIX regexes, PCRE, or any other common regex variant. (Presumably because none of them existed yet when Emacs implemented regexes?)
      - sedachv 7y ago
        Here is a good example: http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/lisp-mode.el#n430 http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-l... DFAs for regular expressions use exponential memory for regular expression size (also exponential time to compile them to DFAs). Try that for the regular expressions in the link above. There is no way to make regular expressions fast.
    - dmortin 7y ago
      > most Emacs modes depend on a lot of regular expressions for syntax highlighting and many other things. Regular expressions are slow I use Emacs every day. Never had a problem with slow syntax highlighting when working on regular source code files. I don't feel regexs are bottlenecks in everyday use.
    - na85 7y ago
      How do more performant editors achieve syntax highlighting?
      - sedachv 7y ago
        https://www.lazarus-ide.org/ https://www.lazarus-ide.org/ does language modes with a parser-generator; the coloring is done on tokens. There is no good reason why Lisp code needs to be parsed with regular expressions.
  - didibus 7y ago
    What are the advantages to replacing the C implementation of Emacs to a Rust based one? Especially in terms of performance, I'm not seeing it, C is generally faster than Rust, so all Rust could provide is better safety no? What needs to be made faster is ELisp, the parts of Emacs not implemented in C basically. Is remacs addressing that as well?
- fmakunbound 7y ago
  If the extension language of Emacs were implemented in Common Lisp, as grandpa suggests, then it could run fine on the JVM using the ABCL implementation, as well.
  - hatmatrix 7y ago
    Or implemented in clojure, which is a more modern lisp...
    - uncletaco 7y ago
      I'm not sure clojure should be the language of choice to compile anything. At that point you might as well implement elisp as a hosted language as well. What papaw was saying up above was creating an elisp compiler for common lisp will make it portable to native code via sbcl and hosted code via sbcl. I suppose one could argue writing it in clojure would make it portable to both the jvm and any javascript engine but what clojure project of significant complexity doesn't break out into the host language from time to time What compilers have been written so far in idiomatic clojure? EDIT: since I'm thinking about it could anyone imagine debugging a compiler in clojure? Talk about stacks on stacks on stacks...
      - didibus 7y ago
        ClojureScript is a Clojure to JavaScript compiler implemented in Clojure. I think that ticks the box.
        uncletaco 7y ago
        True, and that's a good example. I guess what I'm really wondering is how many languages are written in clojure. Clojurescript for instance is just clojure compiling itself.
        didibus 7y ago
        I remember seeing a few toy ones. No real serious languages though. I don't think the parent meant to implement an elisp interpreter in Clojure. I thought they meant to build an Emacs like editor in Clojure. Similar to this now abandonned project: https://github.com/hraberg/deuce https://github.com/hraberg/deuce There'd be no point in re-writing an Elisp compiler/interpreter in Clojure over its current C implementation apart maybe for if you think it be nice for you to work in Clojure instead of C when coding on it.
- lukeschlather 7y ago
  The JVM would probably be a step backwards in terms of startup time.
  - vips7L 7y ago
    Probably, but jvm bytecode can be compiled to native with graal/substrate.
    - pjmlp 7y ago
      And a couple of commercial AOT compilers since around 2000. Additionally all modern JVM implementations have a JIT cache as well.
arminiusreturns 7y ago
I much rather support the efforts to port to guile. Guile is the base of quite a few GNU projects and some effort has already been made on that front. For example one guile based tool I really like is mcron, a cron replacement/augment. https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs
- microcolonel 7y ago
  Guile Emacs, last I checked, was basically working fine. I don't even remember what the open issues were, because I never encountered any.
pcr910303 7y ago
There was some discussion[0] about this a few months ago... (where I was involved & sparked the discussion), and the conclusion was that SBCL & C interop is not as good for emacs. SBCL doesn’t allow lisp functions to be called from C without crossing the conversion line two times, which would be inefficient (esp. since the C functions are written in C for fast speed). I personally think that even with the overhead, adopting SBCL would be an overall improvement, but I’m not maintaining emacs so... [0] https://lists.gnu.org/archive/html/help-gnu-emacs/2019-05/msg00027.html https://lists.gnu.org/archive/html/help-gnu-emacs/2019-05/ms... and the thread following
- guenthert 7y ago
  I have a hard time following that line of argument. I'd think much of the C code has been written a quarter century ago "for speed". Computers are orders of magnitudes faster these days, so we can waste a few cycles here and there. I wouldn't think it sensible to require Emacs to be fluid on computers slower than e.g. an original Raspberry Pi, which is much faster than the early Unix workstations the C code was written for. Said that, while I personally might prefer an efficient implementation of a well documented and standardized variant of Lisp, Emacs Lisp is arguably easier to learn and more appealing to those who just want to customize the editor, which I'd presume it the vast majority of users.
  - sillysaurusx 7y ago
    Not only that, but the runtime semantics are different. ‘foo isn’t a function in CL. But in emacs lisp, it might be. It’s not just a pedantic destination either. ‘(do-foo do-bar) is far easier to write than (list #’do-foo #’do-bar). And you can pass it around more easily. These are all things users want and need. Emacs lisp probably wasn’t designed as a lisp. It was probably designed to be a configuration language, and lisp happened to be the most flexible way of designing it. That’s why stuff like lexical scoping or compiler semantics took a back seat (as it should in this case). Look, I love lisp. You’d be hard pressed to find someone more fanatical about lisp. But CL is... well. CL is CL. You can make it into a config language, but even basics like (require ‘foo) leaves much to be desired. Emacs Lisp is fundamentally simple; most people just don’t take the time to learn the design, and they dismiss it due to the long identifiers and global scope. But the global scope is the power. The global namespace matters. A lot.
emmelaich 7y ago
Maybe try https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs ?

I've always wished Emacs would have been written in Common Lisp. It would already support this, and it's all around just a better language (IMO). There's Climacs, but it's so far behind...

dmortin 7y ago

Couldn't emacs lisp be simply ported to work on the JVM? Then emacs would get a battle tested virtual machine, and the emacs devs could focus on the editor, instead of dealing with VM speed.

sansnomme 7y ago
Keep your fingers crossed for Remacs. Cranelift can probably give it a magnitude increase of speed if things go well. They are about halfway through, give them a hand! https://github.com/remacs/remacs/wiki/Progress https://github.com/remacs/remacs/wiki/Progress If every C/C++ programmer/member of the Rust Evangelism Strikeforce here on HN help port a function, we would have a Rust Emacs in under a month. C'mon everyone, the remaining code is pretty simple and straightforward: https://github.com/remacs/remacs/tree/master/src https://github.com/remacs/remacs/tree/master/src Just mechanical translation to Rust. ONE FINAL SPRINT, and we will be done. The hard work of setting up the tooling and macros are already finished. Many here are happy to moan and complain about Electron infecting everything. Channel your anger into this project! Just help port one function, this isn't even leet coding level of difficulty. If you believe yourself to be a great software engineer, then lend a hand. Don't want Electron editors like VS Code and Atom to be the only game in town 5 years from now? Help translate a couple lines now. It's literally a single docker pull to setup the dev env. Low hanging fruits: https://github.com/remacs/remacs/blob/master/src/indent.c https://github.com/remacs/remacs/blob/master/src/indent.c Tl;Dr: like Leftpad but more ugly.
- sedachv 7y ago
  None of these proposals are going to address the main problem: most Emacs modes depend on a lot of regular expressions for syntax highlighting and many other things. Regular expressions are slow; it is a computational complexity problem. That is, for example, the main problem behind long lines being slow (and why they are not so slow in fundamental-mode). Now that Emacs has multi-threading, pervasive regular expressions are the last big thing that is responsible for noticeable performance issues.
  - sansnomme 7y ago
    What sort of Regex are they using? The garden variety can be compiled to DFAs (O(n)) which a modern computer should have no issues handling. Further optimizations
    - rcthompson 7y ago
      I believe Emacs has its own regular expression syntax that doesn't correspond exactly to either POSIX regexes, PCRE, or any other common regex variant. (Presumably because none of them existed yet when Emacs implemented regexes?)
    - sedachv 7y ago
      Here is a good example: http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/lisp-mode.el#n430 http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-l... DFAs for regular expressions use exponential memory for regular expression size (also exponential time to compile them to DFAs). Try that for the regular expressions in the link above. There is no way to make regular expressions fast.
  - dmortin 7y ago
    > most Emacs modes depend on a lot of regular expressions for syntax highlighting and many other things. Regular expressions are slow I use Emacs every day. Never had a problem with slow syntax highlighting when working on regular source code files. I don't feel regexs are bottlenecks in everyday use.
  - na85 7y ago
    How do more performant editors achieve syntax highlighting?
    - sedachv 7y ago
      https://www.lazarus-ide.org/ https://www.lazarus-ide.org/ does language modes with a parser-generator; the coloring is done on tokens. There is no good reason why Lisp code needs to be parsed with regular expressions.
- didibus 7y ago
  What are the advantages to replacing the C implementation of Emacs to a Rust based one? Especially in terms of performance, I'm not seeing it, C is generally faster than Rust, so all Rust could provide is better safety no? What needs to be made faster is ELisp, the parts of Emacs not implemented in C basically. Is remacs addressing that as well?
fmakunbound 7y ago
If the extension language of Emacs were implemented in Common Lisp, as grandpa suggests, then it could run fine on the JVM using the ABCL implementation, as well.
- hatmatrix 7y ago
  Or implemented in clojure, which is a more modern lisp...
  - uncletaco 7y ago
    I'm not sure clojure should be the language of choice to compile anything. At that point you might as well implement elisp as a hosted language as well. What papaw was saying up above was creating an elisp compiler for common lisp will make it portable to native code via sbcl and hosted code via sbcl. I suppose one could argue writing it in clojure would make it portable to both the jvm and any javascript engine but what clojure project of significant complexity doesn't break out into the host language from time to time What compilers have been written so far in idiomatic clojure? EDIT: since I'm thinking about it could anyone imagine debugging a compiler in clojure? Talk about stacks on stacks on stacks...
    - didibus 7y ago
      ClojureScript is a Clojure to JavaScript compiler implemented in Clojure. I think that ticks the box.
      - uncletaco 7y ago
        True, and that's a good example. I guess what I'm really wondering is how many languages are written in clojure. Clojurescript for instance is just clojure compiling itself.
        didibus 7y ago
        I remember seeing a few toy ones. No real serious languages though. I don't think the parent meant to implement an elisp interpreter in Clojure. I thought they meant to build an Emacs like editor in Clojure. Similar to this now abandonned project: https://github.com/hraberg/deuce https://github.com/hraberg/deuce There'd be no point in re-writing an Elisp compiler/interpreter in Clojure over its current C implementation apart maybe for if you think it be nice for you to work in Clojure instead of C when coding on it.
lukeschlather 7y ago
The JVM would probably be a step backwards in terms of startup time.
- vips7L 7y ago
  Probably, but jvm bytecode can be compiled to native with graal/substrate.
  - pjmlp 7y ago
    And a couple of commercial AOT compilers since around 2000. Additionally all modern JVM implementations have a JIT cache as well.

arminiusreturns 7y ago

I much rather support the efforts to port to guile. Guile is the base of quite a few GNU projects and some effort has already been made on that front. For example one guile based tool I really like is mcron, a cron replacement/augment. https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs

microcolonel 7y ago
Guile Emacs, last I checked, was basically working fine. I don't even remember what the open issues were, because I never encountered any.

pcr910303 7y ago

There was some discussion[0] about this a few months ago... (where I was involved & sparked the discussion), and the conclusion was that SBCL & C interop is not as good for emacs. SBCL doesn’t allow lisp functions to be called from C without crossing the conversion line two times, which would be inefficient (esp. since the C functions are written in C for fast speed). I personally think that even with the overhead, adopting SBCL would be an overall improvement, but I’m not maintaining emacs so... [0] https://lists.gnu.org/archive/html/help-gnu-emacs/2019-05/msg00027.html https://lists.gnu.org/archive/html/help-gnu-emacs/2019-05/ms... and the thread following

guenthert 7y ago
I have a hard time following that line of argument. I'd think much of the C code has been written a quarter century ago "for speed". Computers are orders of magnitudes faster these days, so we can waste a few cycles here and there. I wouldn't think it sensible to require Emacs to be fluid on computers slower than e.g. an original Raspberry Pi, which is much faster than the early Unix workstations the C code was written for. Said that, while I personally might prefer an efficient implementation of a well documented and standardized variant of Lisp, Emacs Lisp is arguably easier to learn and more appealing to those who just want to customize the editor, which I'd presume it the vast majority of users.
- sillysaurusx 7y ago
  Not only that, but the runtime semantics are different. ‘foo isn’t a function in CL. But in emacs lisp, it might be. It’s not just a pedantic destination either. ‘(do-foo do-bar) is far easier to write than (list #’do-foo #’do-bar). And you can pass it around more easily. These are all things users want and need. Emacs lisp probably wasn’t designed as a lisp. It was probably designed to be a configuration language, and lisp happened to be the most flexible way of designing it. That’s why stuff like lexical scoping or compiler semantics took a back seat (as it should in this case). Look, I love lisp. You’d be hard pressed to find someone more fanatical about lisp. But CL is... well. CL is CL. You can make it into a config language, but even basics like (require ‘foo) leaves much to be desired. Emacs Lisp is fundamentally simple; most people just don’t take the time to learn the design, and they dismiss it due to the long identifiers and global scope. But the global scope is the power. The global namespace matters. A lot.

emmelaich 7y ago

Maybe try https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs ?