From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: Shrinking the C core Date: Mon, 11 Sep 2023 17:09:17 -0400 Organization: Eric Conspiracy Secret Labs Message-ID: References: <873503y66i.fsf@yahoo.com> Reply-To: esr@thyrsus.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1854"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Drew Adams , arthur.miller@live.com, acm@muc.de, luangruo@yahoo.com, emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 11 23:09:51 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qfoAH-0000LS-Ud for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Sep 2023 23:09:49 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qfo9r-0001tV-Vl; Mon, 11 Sep 2023 17:09:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qfo9q-0001tM-EV for emacs-devel@gnu.org; Mon, 11 Sep 2023 17:09:22 -0400 Original-Received: from thyrsus.com ([71.162.243.5] helo=snark.thyrsus.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qfo9n-0004FI-Og; Mon, 11 Sep 2023 17:09:22 -0400 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id C2C4718A074C; Mon, 11 Sep 2023 17:09:17 -0400 (EDT) Content-Disposition: inline In-Reply-To: X-Eric-Conspiracy: There is no conspiracy Received-SPF: pass client-ip=71.162.243.5; envelope-from=esr@thyrsus.com; helo=snark.thyrsus.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:310483 Archived-At: Richard Stallman : > 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. -- Eric S. Raymond