5 ms·

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, ins

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.

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.