The Emacs dumper dispute [LWN.net]

The Emacs dumper dispute

Posted Nov 30, 2016 18:56 UTC (Wed) by simcop2387 (subscriber, #101710)
In reply to: The Emacs dumper dispute by felixfix
Parent article: The Emacs dumper dispute

Last I remember about it was this, https://lwn.net/Articles/615220/

The Emacs dumper dispute

Posted Dec 2, 2016 22:52 UTC (Fri) by kleptog (subscriber, #1183) [Link] (2 responses)

Whenever I see discussions about language compilers I think of PyPy. How much work would it be to write a Emacs LISP interpreter in RPython, because then PyPy would give you a JIT interpreter for free.

The Emacs dumper dispute

Posted Dec 3, 2016 8:58 UTC (Sat) by smurf (subscriber, #17840) [Link] (1 responses)

Probably not all that much. Off the top of my head I'd schedule a full-time month to lay out the data structures required and write the code to work with them, another full-time month to cook up a working Lisp interpreter prototype, and a year (part time) to get more optimizations in and all the bugs and kinks out.

The main problem with RPython is that you don't have a dumper any more. Emacs would need to use a lot more on-demand loading, instead of packing everything and its kitchen sink into a dump image, to get initial performance up to acceptable levels.

The Emacs dumper dispute

Posted Dec 8, 2016 17:48 UTC (Thu) by nix (subscriber, #2304) [Link]

The problem is not the interpreter. The problem is that the interpreter is tightly intertwingled into Emacs's C internals -- variables on the C stack often have alternate personae in the Lisp world and vice versa.

The problem is disentangling that such that the interpreter can be replaced, without making Emacs into even more of a maintenance nightmare than it already is.