Bringing GNU Emacs to native code [video]

#1

Post by zeveb » Mon, May 04, 2020, 12:06 PM UTC

Bringing GNU Emacs to native code [video]
toobnix.org

Re: Bringing GNU Emacs to native code [video]

#2

Post by fmakunbound » Mon, May 04, 2020, 2:01 PM UTC

This seems convoluted compared to say moving the Lisp implementation from Emacs Lisp to Common Lisp, of which several native code compiling implementations exists.

Re: Bringing GNU Emacs to native code [video]

#3

Post by wtetzner » Mon, May 04, 2020, 2:07 PM UTC

fmakunbound wrote: post #2

This seems convoluted compared to say moving the Lisp implementation from Emacs Lisp to Common Lisp, of which several native code compiling implementations exists.

You don't think it would be difficult to keep compatibility with all of the existing Emacs Lisp packages that exist now?

Re: Bringing GNU Emacs to native code [video]

#4

Post by widdershins » Mon, May 04, 2020, 2:07 PM UTC

fmakunbound wrote: post #2

This seems convoluted compared to say moving the Lisp implementation from Emacs Lisp to Common Lisp, of which several native code compiling implementations exists.

Rewriting thousands of packages (some of which have had man-decades of work poured into them) would also be rather convoluted.

Re: Bringing GNU Emacs to native code [video]

#5

Post by gumby » Mon, May 04, 2020, 2:13 PM UTC

Note: this is a video. Here are the slides: http://akrl.sdf.org/gccemacs_els2020.pdf

Re: Bringing GNU Emacs to native code [video]

#6

Post by gumby » Mon, May 04, 2020, 2:15 PM UTC

fmakunbound wrote: post #2

This seems convoluted compared to say moving the Lisp implementation from Emacs Lisp to Common Lisp, of which several native code compiling implementations exists.

I assume you mean writing an Emacs lisp interpreter in Common Lisp — which could be done with a small lexer, a lot of macros, and some library support. That would probably be a win.

Re: Bringing GNU Emacs to native code [video]

#7

Post by wtetzner » Mon, May 04, 2020, 2:19 PM UTC

gumby wrote: post #6

fmakunbound wrote: post #2

This seems convoluted compared to say moving the Lisp implementation from Emacs Lisp to Common Lisp, of which several native code compiling implementations exists.

I assume you mean writing an Emacs lisp interpreter in Common Lisp — which could be done with a small lexer, a lot of macros, and some library support. That would probably be a win.

Depends on how difficult it is to integrate Common Lisp into Emacs. Or would you just be rewriting Emacs in Common Lisp?

Re: Bringing GNU Emacs to native code [video]

#8

Post by junke » Mon, May 04, 2020, 2:27 PM UTC

widdershins wrote: post #4

fmakunbound wrote: post #2

This seems convoluted compared to say moving the Lisp implementation from Emacs Lisp to Common Lisp, of which several native code compiling implementations exists.

Rewriting thousands of packages (some of which have had man-decades of work poured into them) would also be rather convoluted.

You don't need to rewrite packages if you have a layer where Emacs Lisp is compiled/interpreted as Common Lisp.

You can easily hack the readtable in Lisp, and rewrite Emacs Lisp sexps as Common Lisp sexps.

Some interesting things to consider are file-local variables, buffer-local variables, dynamic-scope/lexical-scope, how to handle floating point (-0.0e+NaN in Emacs Lisp, custom floating point rouding modes/traps in SBCL for example), but this looks like a reasonable approach overall.

For example (just a draft, this might be incorrect):

    USER> (defun make-local-variable (symbol)
            (eval `(define-symbol-macro ,symbol (bvar (quote ,symbol)))))
    MAKE-LOCAL-VARIABLE

    USER> (make-local-variable 'foo)
    FOO

    USER> (macroexpand-all '(list foo))
    (LIST (BVAR 'FOO))
    T
    T

The BVAR forms would then be able to access a buffer variable, with the current buffer. This works with SETF too (but Emacs Lisp SETQ should be replaced by SETF during the transform).

BVAR could expand into code that calls FFI functions, for compatibility. Using an FFI approach would allow to progressively rewrite some parts of the runtime into CL.

Just to clarify, I know this is a huge work to undertake, but this comes from the assumption that we want to keep all existing Elisp files running identically.

Re: Bringing GNU Emacs to native code [video]

#9

Post by kazinator » Mon, May 04, 2020, 2:31 PM UTC

junke wrote: post #8

widdershins wrote: post #4

Earlier quoted context omitted.

Rewriting thousands of packages (some of which have had man-decades of work poured into them) would also be rather convoluted.

You don't need to rewrite packages if you have a layer where Emacs Lisp is compiled/interpreted as Common Lisp. You can easily hack the readtable in Lisp, and rewrite Emacs Lisp sexps as Common Lisp sexps. Some interesting things to consider are file-local variables, buffer-local variables, dynamic-scope/lexical-scope, how to handle floating point (-0.0e+NaN in Emacs Lisp, custom floating point rouding modes/traps in…

Emacs contains a quarter million lines of C. What do you do with all the elisp that calls into it? Maybe that could be turned into a "libemacs" and used from FFI.

Re: Bringing GNU Emacs to native code [video]

#10

Post by gumby » Mon, May 04, 2020, 2:35 PM UTC

wtetzner wrote: post #7

gumby wrote: post #6

Earlier quoted context omitted.

I assume you mean writing an Emacs lisp interpreter in Common Lisp — which could be done with a small lexer, a lot of macros, and some library support. That would probably be a win.

Depends on how difficult it is to integrate Common Lisp into Emacs. Or would you just be rewriting Emacs in Common Lisp?

The issue is the importance of all the existing packages — invalidate them and nobody will use your implementation.

There are small syntactic differences between Emacs lisp and Common Lisp so a lexer that handled those would suffice.

There are some small semantic differences but they could be handled by porting code. And the Emacs c code could be rewritten in lisp or ported into the Common Lisp implementation, depending on your taste.