Hacker News Reader

Comment by dmortin | Hacker News Reader

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.

View on HN

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

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

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

Tl;Dr: like Leftpad but more ugly.

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.

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

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?)

Here is a good example:

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.

> 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.

How do more performant editors achieve syntax highlighting?

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.

You imagine the rusters think re-writing Emacs in rust is to solve some problem other than the act in and of itself.

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?

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.

Or implemented in clojure, which is a more modern lisp...

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...

ClojureScript is a Clojure to JavaScript compiler implemented in Clojure. I think that ticks the box.

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.

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

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.

I can see the parent misconstruing compiling elisp with building a new emacs-like editor, but the thread (and article) was about compiling elisp.

That being said a clojure editor could be pretty fun, the oy downside being writing native widgets for a gui. I hardly know anyone who uses emacs in a shell if they can help it, and i know far more people who would prefer to use a shell inside of emacs instead.

The JVM would probably be a step backwards in terms of startup time.

Probably, but jvm bytecode can be compiled to native with graal/substrate.

And a couple of commercial AOT compilers since around 2000.

Additionally all modern JVM implementations have a JIT cache as well.

Reply on news.ycombinator.com