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: Shrinking the C core Date: Tue, 29 Aug 2023 05:57:54 +0200 Message-ID: References: <87ledwx7sh.fsf@yahoo.com> <877cpfybhf.fsf@yahoo.com> <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="28042"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 29 13:07:34 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 1qawZI-00071r-I2 for ged-emacs-devel@m.gmane-mx.org; Tue, 29 Aug 2023 13:07:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qawXR-0007xk-7R; Tue, 29 Aug 2023 07:05:37 -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 1qapre-00027G-K6 for emacs-devel@gnu.org; Mon, 28 Aug 2023 23:58:03 -0400 Original-Received: from mail-vi1eur04olkn2010.outbound.protection.outlook.com ([40.92.75.10] helo=EUR04-VI1-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 1qaprb-00086d-7H for emacs-devel@gnu.org; Mon, 28 Aug 2023 23:58:02 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KB/8JtQ4ObCINXeEEs7nVI1K8ls4pwRRJBfG3SDnnYezM/ejKvgDHzWDAUA5hpXki5GdifpaVJKzdwZCw05jpgy6s1G6NWuJo7mg8FjJAKsEebwvar/EdHAaQwA9PbGmDc9+fCRm4WO9WBwN+oyGGXMBtL1/wnwsKPqSHNQWRBjss20PINm++eFBSIBFQqwj1O+m3anQluQlTpW3eHi1lGWzeUICVIm57urzJOw+gfq2sfhleNquTnPOlXVddHEgwk/SK4c6NCrFv2aUrCogoSbxl4U7z2Waq3KdNCYlLPLzhE84+gGyW9i05FLsIUG8DwUTvJfM7JbWYaF/0xqmYA== 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=5p6EwGBABMK7BePkRNbS4v1DkMZcfYVkJFGebeyeenY=; b=mdfDlHj1OJ2chzfcIpkOV9MMU59jnoH4d84mkO9kJT7MnB81T3rHRaJxOw6KvAJLyEONncr700o3tt35AD2pHdtBAfqpyqrF9k7AS1m8RWQyM1mHV7koX2Wz4+OuxV8zehfszi1IcPeMGhPi5wR/9kuh3aQqhCaIpZ57L/JhSclmF45Bb+v06yR4AgTAWsmQB9YwC3LqrjgnTQTW9ts02+z2p4m9vJzvhrwNW1FVe7daUeL67yf4Yl57mnC52WF7ze6kjhUhSaT957Z9q7B82o+JNFzCHYr/CBK3AyfLEvEup6iqQoqRWyqI+Uc+DUSgOMPdKf9EwQiNOuXYKMjSNQ== 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=5p6EwGBABMK7BePkRNbS4v1DkMZcfYVkJFGebeyeenY=; b=HbOSjybPIHM1Xzmby0aMs4SDUXyPPcDF9hwV1YW4OOLrUtoHHp6oKMHRbnLIIR7DNE/cJYEW2r+fNOanmljzGyGVteLpGTbEWILPqitx1Cnufv6f4d8yPs0aKRYDaBX5ciQJuFkUZQTu0l3tbw/nBWGWCu+Gp3LJHB3eadYOKxxCnUQ1PTnU78aTRSCuA3BvmiwWOG3S51FrazQXErJf6CCKrJEBBL3gnoEpSLZ6pp2us3aRDFnWN3/PmPTRN4RbSDLkSohpABjYg/2xTB1J24uKRu9tc9MufF18Dd0p1UtIjzk5411PZpQX9++7RD0ax97nBSHC0V9vm0mbxeBAJQ== Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by GV2PR09MB6063.eurprd09.prod.outlook.com (2603:10a6:150:ba::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6699.34; Tue, 29 Aug 2023 03:57:55 +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.6699.035; Tue, 29 Aug 2023 03:57:55 +0000 In-Reply-To: (Po Lu's message of "Mon, 28 Aug 2023 23:08:58 +0800") X-TMN: [vX/vFHepOB4/2b9NLzOG0nSnOx+FJn6u] X-ClientProxiedBy: BE0P281CA0028.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:14::15) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <82il8y1ovx.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM9PR09MB4977:EE_|GV2PR09MB6063:EE_ X-MS-Office365-Filtering-Correlation-Id: 77f3ffc7-257a-4f9e-676a-08dba8441ff4 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: kCD0BZChktOkF9gxbxy02Eig2YCMNJ1RvbEybMWHLvG0CbGBg78QbWV/pEfUCo4x+KYHJqvSog2CYPAjXNyH0mPRo2E977w01zRU9o0VJFzEi2nyayHp946ZQFN+fFdSIdjICJhaHCpD0Uvcys1NUY5+J2ZG8293spF+ecqivlPAwBha46u6to8exRuuHseehQvfqhPjkrb3PpMaMqRrKYhZ2TI9RX601JI/RSfKoiSlN+PvKwTDOzR7h0YoHno4vmrDpk1TdYnIKhNfa9fNeMatPWTQUC70PcTcMAQwpduuI7ofhoynDj7wJzZcYkL4kpvs6wmSu20WC/mYWMdoqevOu5fRd+yF8R4aQq+tE5HEzgNPkUfqPw2p98MALjY+pQb16otDwyH8pMTcUgdULO9TqnnMlt1zxidXnnp2NTA3YnviMz+BBksHMjsCrP/tmuc3rFnT9R307Gdlf5n7Vj5YHJ/9sHGql8Lj2P33P/ktmTK8YiXRuncThZ4qHzdFdHaMkidI75Br4Y70foTwdnG03SZ5bEO3OuVtqhKZ5Tg= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?AXAV2AmpFJYtlV2yQ/wIBnzv3yipvMltupXm3OXen0GRYeziCKqYD4zF1meP?= =?us-ascii?Q?uFHJlZ6x2Ygpak3kBP6qhpqwYy9gMbABr9yvYqcXEs1AXLsxla+xvEKixXiS?= =?us-ascii?Q?p0c93hxBWit8i060joealdVP34N39FgY5Ha/aqCZFriVaJl4jBP9ksJBjx7L?= =?us-ascii?Q?ZQPI/mQHlKeNkMXCXuylIfddBsVHwQqGinyHRUFbuIhxy6uyo/LPCaQNZ6xc?= =?us-ascii?Q?1fTfubeW5Req1kSjZTlHC1nBLGL6bOGtXkA9xSeueowtrSbquaCLJbxsjM50?= =?us-ascii?Q?vHg5XeCXTJJ0Kucegtf71amtl8QTcp9pcUFRkUa7zYO960fCdjhBVbGQ4IRu?= =?us-ascii?Q?nVStPKF+Y0LyWc2DpxoYrPFDUpP25J4kmTCsXk9Du/Ca5Y09zguLBiXLY15B?= =?us-ascii?Q?1az+xmk9Xa4TbLp3fgwvMoFlGmubed1C80a6L9KsavntBCUaYMilEEWmY85S?= =?us-ascii?Q?Y5gKKEs3QhznxZ2BjaibDmgaoOaTj4AhrmVYrfrJy8cMxrc4rdAADbdeDyg7?= =?us-ascii?Q?3vu8qbToVowt2EI/8yI2nqb2HrTDfXZsuZE/XJIhZ8JPHArvjgrNYDPw1xmw?= =?us-ascii?Q?s637ZDgNrfDJi5B0CM/OhYX1cjdj2fOBXMG6k2u5k1O9hZRmEzg3kLsFbEEU?= =?us-ascii?Q?+H X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-64da6.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 77f3ffc7-257a-4f9e-676a-08dba8441ff4 X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Aug 2023 03:57:55.5141 (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: GV2PR09MB6063 Received-SPF: pass client-ip=40.92.75.10; envelope-from=arthur.miller@live.com; helo=EUR04-VI1-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_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 29 Aug 2023 07:05:30 -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:309488 Archived-At: Po Lu writes: > Arthur Miller writes: > >> Unix which? Unix is not a single program; it is a family of operating >> systems, and I am quite sure nobody runs the same kernel they did back >> in 1970. I don't know what you are talking about you have >> "demonestrated". You said yourself *was* and not *is* which suggest >> that those kernels are rewritten in order to support those C programs >> that can be interlocked. Again you are constructing yourself things >> here: I haven't said it is impossible to write mulththreaded C >> application that can use locking. > > Each extant Unix system today contains gobs of code derived from the > Unix kernel developed at BTL in the 1970s. None of their kernels were > ever rewritten -- rather, they were subject to iterative refinement that > eventually allowed them to operate on SMP systems. > >> There are many applicaitons that have been redesigned. Emacs has been >> redesigned since its first incarnations as TECO editor if I have >> understand the history. For the very last time: I haven't said Emacs >> *can not be redesigned*, on the contrary, I said Emacs *should be* >> redesigned. Emacs core so to say. You are fighting against things I >> haven't said; I don't know why, if it is lack of English skill, or >> something else, but we are talking constantly beside each other. > > Perhaps you define the word "rewrite" differently, but its customary > meaning implies a reimplementation from square zero. My point is that > doing so is a gratuitous and unnecessary gesture, and we would be better > served by more realistic assessments and consequently more reasonable > proposals. > >> Are you saying that a non-multihtreaded program written in C can >> suddenly become multithreaded without being re-written to support >> threading? Nevermind, you are totally, on purpose or lack of >> understanding, missing the point: you have to rewrite stuff to make it >> multithreaded regardless of the language if you intention is to have >> Emacs core multithreaded. Supporting multithreading is not same as >> having entire Emacs internals be multithreaded. > > Since when does interlocking call for a rewrite? > >> No, it does not because you have missunderstood that I mean something >> else. > > Then clarify what it is, for the plans you present (rewriting Emacs in a > different language) sure resemble plans for a complete grounds-up > reimplementation. > >> I propose porting core API to Common Lisp because that would save you >> implementing all those things that you need to make Emacs >> multithreaded, better GC etc, because it is not a trivial task. > > At the cost of portability and control? No, thank you. > Let me ask a question in turn: how many of the popular and often-cited > Common Lisp implementations are as old as Emacs? What guarantee is > there of their continued existence 10 or 20 years into the future? > >> Of course you can re-write all that stuff in C too, nobody is denying >> that it is possible. I am saying there is no need to reduplicate the >> work, and there are other benefits of having Emacs in Common Lisp. > > The work to be duplicated is menial and more-or-less already complete. > The remaining bulk will need to be tackled irrespective of the language > used to implement Emacs. The conclusion as to whether we should > overcome that bulk as-is, of if we should compound it with the challenge > of rewriting Emacs in a new language, is left as an exercise to the > reader. > >> Look harder. > > Any examples? > >>>> Well yes, C is portable and fast, nobody denies that. So are some >>>> CL >>>> compilers. >>> >>> Which Common Lisp compiler is capable of linking with Java code >>> through >>> the JNI? (ABCL doesn't work, as the Android JVM can't interpret the >>> bytecode it generates.) >> >> I don't know what you are trying to say; that sound like very >> uninformed statement based on missunderstanding. Calling Java via >> native API and generating bytecode that runs Lisp on top of Java as >> ABCL does are two completely different and separate things. I am quite >> sure Emacs does not generate Java byte code. But I don't see how is it >> even relevant, I haven't suggested to run Emacs on JVM. Perhaps it is >> possible who know, but I have suggested to use sbcl which is a native >> compiler specialized for compiling Lisp (and runs on Android as well). > > It's not possible to load a Common Lisp image into the JVM, because the > Java linker is only capable of linking compiled C objects that export C > symbols. Therefore, SBCL cannot run within any GUI Android program, > given that they must be started from Java. > >> "only" ? :-) I can asure you that Lispers have access to both kernel >> and user space threads. Search on Bordeaux threads. > > That's only a wrapper library for the incoherent threading primitives > furnished by different Common Lisp implementations. > >>> garbage collection strategies vary between machine types. I'm sure >>> we >> >> Does it? > > Yes it does. > >> I am also sure everything is possible, it is software, as a wise old >> grey head once said. It is just how much effort and resource you are >> pouring into it. SBCL runs on basically all important platforms on >> which Emacs runs, minus as mentioned DOS and Windows95; I don't know >> if there is some other. But it is not the point. The point is: there >> is another community working on the same problems you have or wish to >> solve. And they have come far away than you. You could re-use their >> work, and if you miss somethign add those missing parts so everyone >> would benefit, or you can live in an isolated island and do everything >> yourself. > > C is hardly an "isolated island". Anyway, we need a portable, fast, > flexible and ubiquitous language, and Common Lisp doesn't fit the bill: > if a platform as anodyne as Android poses problems for it, what about > the next sandboxing contraption for Unix systems? Or any future system > whose appearance down the line we cannot anticipate now? What if our > requirements outgrow Common Lisp's capabilities? > >> I am telling you that sbcl/ccl has already solved those problems you >> have to solve in order to have multithreading without having to lift >> your lock. > > We have too. What we have not, they cannot offer either. > >>> Instead of denigrating the C language, Emacs's C core, and so many >>> other >>> components critical to Emacs that have been subject to unjustified >>> invective in recent times, why not direct your attention to a more >> >> I don't think I understand how I "denigrate the C language" and what >> "unjustify invective" in this case is, but I don't think it >> matters. Once you also said I should be forbidden to talk about Emacs. > > It does, because such motives drive people to engage in many hours of > time wasting wild goose chases, all to ascertain which language > Providence meant for Emacs to be written in. > >>> direct your attention to a more >>> productive task, such as identifying the complex interdependencies >>> between different pieces of Emacs's global state to establish a >>> detailed >>> plan for their interlocking? For this task, the most important tool >>> is >>> a control-flow visualizer such as cflow, and an ample supply of >>> paper. >> >> Can we save nature and our selves? > > Parse error, sorry. > >> Nor are you sole Emacs devs, aren't you? I don't think calling names >> is appropriate, so I want, but I can come up with at least four people >> who work on Emacs and who are experienced Lispers. How active they are >> in development recently I don't know, I don't follow the list every >> day as I am used to, but I certainly haven't targeted Eli nor you with >> that one. > > Names? Would they be willing to take responsibility for the areas which > we oversee, in the event a Common Lisp Emacs comes to pass? Perhaps this recently released paper might be of interest to you: https://applied-langua.ge/~hayley/swcl-gc.pdf