Re: [External] : Re: Shrinking the C core

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
> Switching to Common Lisp would cause those painful incompatibilities.
> It is unacceptable.

I did some checking into this a few weeks ago and even wrote a bit of Lisp to do
an audit.  There are other reasons I decided to get up to speed on Common Lisp
recently, and because I have Emacs Lisp engraved on my forebrain this interested
me in getting a good grasp on how incompatible with SBCL it actally is.

Count of elisp core functions: 1476 
Total SBCL/elisp function name collisions: 145 
Primitives identical in elisp and SBCL: 116
Primitives not known identical: 28

The first two lines are crunched from querying SBCL's symbol list and
groveling through the Emacs sourcefiles; I can supply the SBCL code I
write to do this if anybody cares.

The second two lines are from me reading the SBCL documentation a lot;
I needed immediate motivation to do that and this was a good one.

I was able to write trivial implementations for 15 of those 28 collisions.
The 14 I didn't implement are these:

(require read-char read random process-status process-plist print
princ prin1-to-string prin1 load documentation defvar aref)

What this means is that it would, in principle, be possible to write
an SBCL core that implements all of the Emacs primitives, with only a rather
small amount of shim code required to make existing elisp code execute
in an environment where it thinks it sees *all* elisp primitives.

The code would look something like this, where I have deleted all but one 
emulation
to showcase setting up the emulation environment.

        ;; Implement functions shared between CL and elisp in an elisp-like way

        (defun elisp-append (&rest sequences)
          "(append &rest SEQUENCES)

          Probably introduced at or before Emacs version 18.
          This function does not change global state, including the match data.

        Concatenate all the arguments and make the result a list.
        The result is a list whose elements are the elements of all the 
arguments.
        Each argument may be a list, vector or string.
        The last argument is not copied, just used as the tail of the new list."
          (apply 'append (mapcar
                          (lambda (it)
                            (if (listp it) it (listp it)))
                          sequences))
          )

        (defmacro within-elisp (form)
          "Evaluate FORM in an environment with elisp behavior."
          `(flet ((append #'emacs-append)
                 (delete-file-internal #'elisp-delete-file-internal)
                 (eval #'elisp-eval)
                 (format #'elisp-format)
                 (intern #'elisp-intern)
                 (make-hash-table #'elisp-make-hash-table)
                 (make-string #'elisp-make-string)
                 (rename-file #'elisp-rename-file)
                 (sort #'elisp-sort)
                 (string #'elisp-string)
                 (string-equal #'elisp-string-equal)
                 (string-lessp #'elisp-string-lessp)
                 (symbol-value #'elisp-symbol-value)
                 (type-of #'elisp-type-of)
                 (unintern #'elisp-unintern)
                 (yes-or-no-p #'elisp-yes-or-no-p)
                 )
            ,form)
          )

With this encapsulation, "painful incompatiblities" between elisp and
a core written in SBCL would never need be visible to anyone who put
an .el extension on their code to tell the core it should be executed
using within-elisp.

I'm not minimizing the amount of work an SBCL core would take,
there's a lot of devil in the details of 1476 + 14 primitive
functions.  Nor am I interested in joining a political argument
about whether it should be done; I have too much else on my
plate for that.

But it could be done. There is a technical path forward to it.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>