Re: On elisp running native

[Eli Zaretskii <eliz@gnu.org>]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 26 Dec 2019 22:10:56 +0000
> 
> What do think about the general idea of having a compiler able to native
> compile elisp?

I don't feel I know enough about programming language theory to give a
useful technical opinion.  I can only try to play a devil's advocate,
and mention a few potential issues with such an approach:

  . it will need a compiler (and GCC at that) on the end-user system
  . the code it creates must be used on the same system, or on systems
    of very similar architecture, so it will be harder to distribute;
    e.g., release tarballs will be unable to include such code, like
    we do now with *.elc files
  . I wonder how you solve the problem with dependency on libgcc and
    its likes? this could be another source of reduced portability

> What do you think about the proposed design (Lisp -> LAP -> LIMPLE ->
> libgccjit -> elf)?

Again, I have nothing intelligent to say about the technical aspects
and validity of this approach, only about its practical implications.

This means it's GCC-specific, and moreover requires native support for
loading ELF objects, right?  Which means it will probably run well
only on GNU/Linux and maybe the *BSD systems.  That's a bummer for me
personally, because my main development machine runs (gasp!)
MS-Windows.  IOW, I will never be able to run or debug this feature,
except by remote login to a GNU/Linux system or some other equally
inconvenient method, because neither ELF loading nor libgccjit are
available on my system.  (Or maybe you intend to make both happen on
MS-Windows as part of your work? ;-)

> Do you see any weakness in some part of the design you would be
> particularly worried about?

See above.

I also wonder about the debugging.  If this feature goes prime time,
at first I imagine we will need to debug problems with generated code
quite a lot.  And since Lisp code frequently calls back into C, we'd
need a good way of debugging them both, and being able to relate the
generated code to the original Lisp while at that.  If this is not
possible, or hard to accomplish, and will require people to step
through generated code on the machine language level and correlate it
with Lisp in their heads, it would mean only a handful of people will
be able to solve any such problems.

A typical situation is that Emacs segfaults, and the immediate crash
locus is a bunch of machine instructions -- how would one go about
debugging this?  (A similar issue exists with debugging faulty
bytecode, but since the byte compiler is very old and mature, this
almost never is of any practical importance.)

> Do you see in this a potential for having it up-stream in the future?

Yes, assuming you (and any others who would like to actively work on
that branch) will have enough energy and motivation to bring this job
to its completion, including reasonable solutions to the debugging
issue, support for all Emacs configurations we care about (a frequent
gotcha is 32-bit builds --with-wide-int; and what about
--enable-check-lisp-object-type? etc.), and then support it during the
initial stages of its use on master, when people will almost certainly
report problems with it that were never heard of before.

I realize that the above sounds negative, and maybe even discouraging,
and I apologize for that.  But please bear with me: if I'm allowed to
put on my project management cap, I have some bitter experience with
several experimental features which required a significant amount of
work, but were abandoned before becoming mature, or were merged
although they weren't mature enough, or whose developers disappeared
without a trace, leaving us to cope with the problems reported against
those features without enough knowledge about the code.  So I think
for such a radical new feature, which affects how we compile Lisp, we
(at least I personally) would like to avoid such disappointments as
much as practically possible.

Thanks.