From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: Shrinking the C core Date: Tue, 12 Sep 2023 04:05:01 +0200 Message-ID: References: <873503y66i.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21106"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Richard Stallman , Drew Adams , acm@muc.de, luangruo@yahoo.com, emacs-devel@gnu.org To: "Eric S. Raymond" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 12 04:20:38 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 1qft13-0005Ke-VI for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Sep 2023 04:20:38 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qft0B-0008D8-UN; Mon, 11 Sep 2023 22:19:43 -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 1qfsm5-0005ws-6V for emacs-devel@gnu.org; Mon, 11 Sep 2023 22:05:09 -0400 Original-Received: from mail-dbaeur03olkn2079.outbound.protection.outlook.com ([40.92.58.79] helo=EUR03-DBA-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qfsm2-0001pa-Hu; Mon, 11 Sep 2023 22:05:08 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AC7dT1YadJ0drnTjzg/B2xwXPFuidlPCTFTqvPgu3u3F1k6Tpe1SgymfaZegTpa+aqpXDg1SBuWet/1PQTiogEprV/Ef6Ah52itF+JaetLa52z60XQ0srdoGgUxKvz7ARUq/Q6I0HvNmB0VacAv4pc/Tjq4Fhi7mD0lqYBL5TNu0uYr7c/Duce18HJQp406ehurEf0RekpSalc3EDHUdXHDwpT3zxv6CNDEAPavLtH3FIfIKfuBtP1ryzTN97Bc2gjfgbwyk5Dk3tnvs4ZHJENY9Kto4SbRsL5KU1nGftbugwDC3pPRVrEFdgh1VKLQwpKxrEGQNPiO+WkWLBacOdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xZU7QYqQr1Pba6VMZCDvdBaSB3eM8hvnCuvVvHpPyy4=; b=Lsnp0RWY48k6DMjhUiOtFlrEQQ6gORKjs7yHnq8L82STN7jsG5CbaZK+r/lJJp19Pr/Y09DJS17QPdhSzH/joWOQP0B2Ju0zr1S+k4rP4C1kKnkrcbqbM/X8Mcma+TcORAt8hBTtS8VkL1XQkjcHiDqMoA84Ke5ckhrjyok4hvC4n6qUH9uuZUYtzJQgKIM21aet5KagcQt6R9RSgQA33oVjD5H4vomO3dTGTpnLAQOQwj4fNmSdRcZNpr4CC8G41pln6zbep5kcmsVdOcAlmhpEWqWcI0GWGaxOfxpNz52+rNeG3A+WDaC7ybwGBh8glz3SzCKnvxulTXXKpZ1Crw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xZU7QYqQr1Pba6VMZCDvdBaSB3eM8hvnCuvVvHpPyy4=; b=jJL7OhICppp7wIcNqgDe1iPUCSk8nW0JEzlrZtAwfhyYrccvFL4A8Y+ZyOdKYKZyoIfQRbofGiijgaE4+T+yUKn/4742eCMAOagbZHxcv6zYl9DTmJE0ipaxqdjMGE7aAW+/Hs2yyBNK4kyL65GlrJogKSbbBHBiCJJY46S69GhQ9w6AU3p3Dj2vMshnX6MDjSAtq2XSV3yIpie8xlU5E4pSDL8QJynRN5dNR4ww8iZrbF1BQGFOnv0MbDlJVKDc3rEOtZVf0SgCgYGNpY+aj/UY4N9ZpynjmUf/Pca1wjDcySZ8X7uh0VxvE5ln/r72i1HIYy4cBxyHi65t1Iil9g== Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by AM9PR09MB4546.eurprd09.prod.outlook.com (2603:10a6:20b:280::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6768.35; Tue, 12 Sep 2023 02:05:04 +0000 Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::df56:b1b1:64b1:6122]) by AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::df56:b1b1:64b1:6122%7]) with mapi id 15.20.6768.029; Tue, 12 Sep 2023 02:05:04 +0000 In-Reply-To: (Eric S. Raymond's message of "Mon, 11 Sep 2023 17:09:17 -0400") X-TMN: [VIhSBiNFK/VkpYxUyNKY8uFu5Tuv6KCV] X-ClientProxiedBy: OS6P279CA0143.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:3a::14) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <82edj45epe.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM9PR09MB4977:EE_|AM9PR09MB4546:EE_ X-MS-Office365-Filtering-Correlation-Id: 9cd21059-b964-4f58-4b9d-08dbb334ada6 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: uC27r43pOwuygoYXEH6k8T4/2Gg1hQym4hcIZYcyleFzmrz4JfmOTqLjmwcjeYsBoTUWWKcz9svrWl4NsHGkiWY+oEU5LbVaFA7KU7aAzUuNXbt2cqhS8GuewmI5/wtpvyCeGmv6qa2GefAMs4sSnto+/hahVa2G8tTKArNs0uzxSnlJVm0a0dzRdkXSmI9GSJcz21IUEvzVkenUhzYWImxOwcABH5iio/QSF8GLBUih+wqZ6XgByX3L53qZLZZyQ8ZUcMY6Paj/V3CuRMrrz+BeBYgsxpQruYRkhGlzQpev/z9zzQHFL5pojRDdNMTBK8I1MzyUZEoVaHBg6OZY6oIsdjGFW5OiTsoJKyYdZejkTSKb6aOqPmsZU4xfS/PfwLxyKJAAuAM4r7GInubsyEL62ttvsczsPXcn1neMrQQR0j7MJvLk0byniefBRfHvzw+IpD7SXVgO41yTLVP+PoDUPlIny396dhsfWTsbfLa92VjMHunY13IyXtnB127pgcX7dMny7+Cpyf886Oh30ny3w52mTNVQm61VjrmgXCoxq+SZI0/QVd/dNaODNGf0 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?D5ILSY8JNySaegjkGm/KIKiA4yFX2MsG06qD+BvhmK/yhYOAFr8UokIQp5R8?= =?us-ascii?Q?y+ZhWKtjT7As/FgsDD/017sZavHBs0MU+2swMppTOLWphTJ2rckJSyHa5eGw?= =?us-ascii?Q?dLZ0Dcv9ahYYRVnkaWJ/X/KaYSgA1SFG1589bUAt3r0jpXGlSn8X5IcxGmgU?= =?us-ascii?Q?xLtIQX455yoLsqOFXJg+z8EnaRjwCXqzVydVO4epENF36fa7kVu1rqkv3XYv?= =?us-ascii?Q?RmXPr/YP61H2Uz+D7JYRsP41k8qrpjXQXtJFzTD0E60pj5+DP9uDiUuaF+6t?= =?us-ascii?Q?19ZklR/CIlZccD3hsIkf0xKd49i3jXMjYtYFGlk8Z0Kbvsrybc/gyVKu9yWX?= =?us-ascii?Q?w76Q34erIvwSmpLelvXYf/GUFfNaz1a23gVpWdbUn2qnVlHP0XeafL4S3Bc1?= =?us-ascii?Q?JR9ZkIgn6ijXnH2n6GjOYKoSGRXLxgUVQF4/ywO6K/4h4oVKzLPW325yFC9H?= =?us-ascii?Q?RTvqkaBefRFA6Mrg3GHQrMnrSqkbu+lAdoZgONgB3WQD9thE+BQ2iptYnX1r?= =?us-ascii?Q?koVxhvSlXPcwmdVoXtp3YsATE2Rfec8udcMm+Arw+xwGnuKtNKd6wcxu+Wa4?= =?us-ascii?Q?PDM9QBgWRv62iCUzvGbkNISbdmQMwQnqo+Wzw9NP+EOclG6marMIww2dr5Yk?= =?us-ascii?Q?lR X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-64da6.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 9cd21059-b964-4f58-4b9d-08dbb334ada6 X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2023 02:05:04.1117 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR09MB4546 Received-SPF: pass client-ip=40.92.58.79; envelope-from=arthur.miller@live.com; helo=EUR03-DBA-obe.outbound.protection.outlook.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 11 Sep 2023 22:19:40 -0400 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:310495 Archived-At: "Eric S. Raymond" writes: > 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. There is a little bit more than just this; but that one was very clever to smooth out basic differences. It all depends on the ambition of course. I do wrap cl funcitons and re-implement some of those that are missing in CL just to be able to attach the doc strings to symbols, and counting on sbcl inlining to remove the function call. I am not sure yet if it is a good strategy, but I can do it relatively automated. Looks like this: (defun take (n list) "Return the first N elements of LIST. If N is zero or negative, return nil. If N is greater or equal to the length of LIST, return LIST (or a copy)." ;; todo - this can probably be done without taking the length of the list (cl:when (cl:> n 0) (cl:let ((l (cl:length list))) (when (cl:> n l) (setf n l)) (cl:subseq list 0 n)))) (defun ntake (n list) "Modify LIST to keep only the first N elements. If N is zero or negative, return nil. If N is greater or equal to the length of LIST, return LIST unmodified. Otherwise, return LIST after truncating it." (cl:when (cl:> n 0) (cl:let ((l list)) (eli:while (cl:and (cl:> n 1) (cl:cdr l)) (cl:setf l (cl:cdr l)) (cl:decf n)) (cl:rplacd l nil) list))) (declaim (inline nthcdr)) (defun nthcdr (n list) "Take cdr N times on LIST, return the result." (cl:nthcdr n list)) (declaim (inline nth)) (defun nth (n list) "Return the Nth element of LIST. N counts from zero. If LIST is not that long, nil is returned." (cl:nth n list)) But tere is more than just functions and macros. The reader needs some help; Emacs uses different syntax for characters and escapes for example; ? vs #\, but the escape syntax is were a real hear pulling is. Also Emacs does not have character type but basically uses whatever int comes out of C and thus Emacs API can do arithmetic operaions and comparisons on characters whereas in CL they have to use character specific operators. I have implemented the reader to understand ? and escapes and to spit out integer codes instead of cl characters so I don't need to dispatch on each mathematical operation. There is still more, "markers are numbers" in Emacs, so mathematical operations are applicable to those as well. I haven't decided if I will do same as they do in C sources or I'll try to implement static dispatch for generic functions and have mathematical operations as generic functions, I have to test how it works, but there are other things like those that have to be taken care of. And there is more, that is just the tip of the iceberg :). I am also talking only about lisp implemented in C core. There weould be need to do some work on the elisp side too; eieo, cl-lib, defun/defmacro, stuff like that, but that is probably by far lesser and easier to fix. > 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. Yes, something like that; it is volumous and lots of work, for one person probably impossible, but it is not impossible to do.