From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Wed, 09 Aug 2023 15:45:51 +0300 Message-ID: <83y1ikl6yo.fsf@gnu.org> References: <20230809094655.793FC18A4654@snark.thyrsus.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23172"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: "Eric S. Raymond" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 09 14:46:11 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 1qTiZn-0005nT-Ht for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Aug 2023 14:46:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qTiZC-0001HF-Lx; Wed, 09 Aug 2023 08:45:34 -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 1qTiZ8-0001FM-CB for emacs-devel@gnu.org; Wed, 09 Aug 2023 08:45:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qTiZ7-0005a3-So; Wed, 09 Aug 2023 08:45:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=W0WreF5k0BtAOsRskm24xTe7OCu3UDI+9BIOcaQqPKw=; b=qIWVNtRiVULy mfb9gbl1zGdn0hHPmyvzTEJJWZDAcBkH6L6xW6uyxAjVVcjXxi5Hr7BY0HOI6DHebGLrsTCC9ohDc Fhkl5eiQvWmoA6lLGS9NkecHfrnNNBMDZ3RVS4KMjmdTkv+YT+x2qrFivv9/lcRPXofnwFrXxvBx0 PMiZRNlIeIRu1QuRZndZIHEOSrkHc08/xv8SO8w5DM2L1hzraqJf2UjwMN5jaopD7/UOg6tesOo1a GX5cBJ1CphwmK9Fum/i3Lr4xLf1DKtxryVDgTOG174fFIqShiasNVpT+c6NujmxqquIZyuGPZdQvS Gw/wLW32a4gHVyMPMMQExg==; In-Reply-To: <20230809094655.793FC18A4654@snark.thyrsus.com> (esr@thyrsus.com) 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:308471 Archived-At: > From: "Eric S. Raymond" > Date: Wed, 9 Aug 2023 05:46:55 -0400 (EDT) > > Why is this in C? History, I'm quite sure. > Is there any reason not to push it out to Lisp and > reduce the core complexity? More generally, if I do this kind of > refactor, will I be stepping on anyone's toes? For veteran and stable code such as this one, we should not rewrite them in Lisp just because we can. We should have much more serious and good reasons for such changes. Good reasons include adding some significant new feature or extension, supporting new kinds of filesystems, etc. Otherwise, this just introduces unnecessary instability and maintenance burden into code that was working well for eons. Even the simple change you did a few days ago broke the build on one system and raised a couple of issues some of which are not yet resolved, and others we don't even have a good way of resolving except by bracing for bug reports. In addition to the obvious issues with moving code from C to Lisp, there are a few less obvious. One example: functions defined in C are always available, whereas those defined in Lisp are only available once the corresponding Lisp file was loaded. This matters during loadup, and even if currently we either don't use the affected primitives during dumping, or use them only after the corresponding Lisp file is loaded, it makes the build process more fragile, because now changing the order of loading the files in loadup or adding some Lisp to loadup and other preloaded files runs the risk of breaking the build due to these dependencies. Another example: moving stuff to Lisp causes code that previously couldn't GC to potentially trigger GC. So now various parts of Emacs which call this primitive from C will need to be prepared to have GC where they previously could assume no GC. How do you even assess the risks from that in a program like Emacs, what with all our hooks etc.? This is not academic: we had and have these problems all the time, and they are usually quite hard to debug and solve. We don't need such gratuitous maintenance head-aches, and we don't need the risk of introducing subtle bugs into code which worked for decades and which we are used to rely on and trust -- unless there are very good reasons for that. And good reasons in my book are only those which develop and extend Emacs, and add new and useful features. So please let's not do that without such reasons. New code that adds new primitives -- sure, we should discuss whether this or that part needs to be in C, and prefer Lisp implementations whenever we can. But not the old and trusted code like this one -- those should be rewritten only for very good reasons. And even when we do have such good reasons, whether they justify rewriting existing stable code should be discussed on a case by case basis, so we could consider the possible alternatives and choose the best way of doing that. Not every extension that involves some primitive justifies rewriting or reimplementing that primitive.