From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.tangents Subject: Re: Shrinking the C core Date: Wed, 13 Sep 2023 08:33:43 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34801"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-tangents@gnu.org To: Arthur Miller Original-X-From: emacs-tangents-bounces+get-emacs-tangents=m.gmane-mx.org@gnu.org Wed Sep 13 15:22:06 2023 Return-path: Envelope-to: get-emacs-tangents@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 1qgPoh-0008mz-Vy for get-emacs-tangents@m.gmane-mx.org; Wed, 13 Sep 2023 15:22:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgPma-0001yZ-7A; Wed, 13 Sep 2023 09:19:52 -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 1qgJRf-0002z9-Fq for emacs-tangents@gnu.org; Wed, 13 Sep 2023 02:33:51 -0400 Original-Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qgJRb-0001OA-SG for emacs-tangents@gnu.org; Wed, 13 Sep 2023 02:33:51 -0400 Original-Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-50078eba7afso11173173e87.0 for ; Tue, 12 Sep 2023 23:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694586825; x=1695191625; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=g0REag4VN0PQew3G1Ohhk9w6PKmdKmr3N8OlzdGf68U=; b=JO2MDMXm0v6FL91VhoPUC10iTkLOEk1J2qh4STt3xPKQu0OKh8rVCqFqen4hBVCKJJ nEWqjBvXdMrmFUKqnh9hzGIpF+AFvek7MRkTjQgqpdQmT+9RDp/pTJ8VS+ruYgqUDU18 0mHRXTNx+UUkNEzE8FOhspNfVF9+zbgdeVPld1SdKZIrUnLbb70l/efPq1daOWmDXHgr RlYmaGQxa0QYYN8TMX7COasJ8i4ZL4J7xSkd5tnHTrg9IxHw9XhiwUcpSKxIaxMWVe0R XZmBzas8STfeC69ib8vhsRQYUeniO6K+Kh4LuE64ZGSa5RwthyCGtBIcBp1mG5AcpyN1 hHbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694586825; x=1695191625; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=g0REag4VN0PQew3G1Ohhk9w6PKmdKmr3N8OlzdGf68U=; b=YYb5m1hue8qrAUs/AIYixag3EZlrKcBTi53c98KWx+uhTG5wo5dhMuEuQFDbvje/Kp YQKcLtxt8hknW4T8nm1hQnjQmIjZN1etCUp1SOZsCR9haxUdvDCO55EWFtHJhPvrRJV/ 7tJfJNKwq2+fNcL0jBmInj8CwOOp5KYcR0glZsnaYB6vgmpT3cfei+Uv/dC106FpRkFD vJpTdRklASm+DxT254QcFbymO4yhiTJOnAqmGj+CmVg6/ofNm97pfd00II7J5tZHHppw hB6Jnwnklh8Y+0yk8a+ahU8EoXq1wVjyYFE7qRvRowHmnogYX2BhUnzFtZdl/kQiKJuv YcpA== X-Gm-Message-State: AOJu0YwL209GlgR/UX6YrrfgOliw2emtO01R5nZe4qj0n700P1R3TYUk ReUK2bjClWuRTN/7v9hhuhglWWXSuii+2Q== X-Google-Smtp-Source: AGHT+IGjR7xAU8RtA8BCJn4M7EluUyIL24BGmE+z6s2Bfm8Sh77IJ/cYpn/OuBz2PmNgil1+7NvU9g== X-Received: by 2002:ac2:58d6:0:b0:4ff:8f76:677f with SMTP id u22-20020ac258d6000000b004ff8f76677fmr1090399lfo.67.1694586824595; Tue, 12 Sep 2023 23:33:44 -0700 (PDT) Original-Received: from Pro.fritz.box (p4fe3a1ac.dip0.t-ipconnect.de. [79.227.161.172]) by smtp.gmail.com with ESMTPSA id r25-20020aa7d599000000b005256d80cdaesm6717246edq.65.2023.09.12.23.33.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Sep 2023 23:33:44 -0700 (PDT) In-Reply-To: (Arthur Miller's message of "Wed, 13 Sep 2023 07:06:07 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::12b; envelope-from=gerd.moellmann@gmail.com; helo=mail-lf1-x12b.google.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 13 Sep 2023 09:19:50 -0400 X-BeenThere: emacs-tangents@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-tangents-bounces+get-emacs-tangents=m.gmane-mx.org@gnu.org Original-Sender: emacs-tangents-bounces+get-emacs-tangents=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.tangents:1076 Archived-At: Arthur Miller writes: >>> IMNSHO, discussing a rewrite of Emacs in _any_ language is waste of >>> time and energy. We've seen this many times (because people still >>> insist on bringing this up from time to time). From where I stand, >>> the main reason is not even the fact that we decided not to do that, >>> but the fact that such a rewrite will never happen in practice. Such >>> a rewrite is a massive job which requires very good knowledge of Emacs >>> internals and features, and a lot of time. People who come close to >>> the required knowledge level are not interested in doing this job >>> (because they understand the futility), and those who think it should >>> be done simply don't know enough and/or don't have enough time on >>> their hands to pull it through. >>> >>> If Emacs will ever be "rewritten", it will not be Emacs, but a >>> text-processing system with a very different architecture and design, >>> which will take from the Emacs experience the lessons we learned and >>> implement them differently, to produce a system whose starting point >>> is closer to the needs of today's users and whose main technologies >>> are more modern from the get-go. >> >>I couldn't agree more. >> >>To me, a rewrite is quatsch, while adding CL facilities to Emacs makes a >>lot of sense. > > I use to say often: either CL will come to Emacs or Emacs to CL, whichever > way around. We need some of features available on CL platforms, sbcl > notably: built-in concurrency and better garbage collectors from the get-go; and > some of the CL language features, namespaces notably, would be very nice to > have. I agree. Alas, others, who haven't seem the light yet, don't :-). > I am not sure which one is easier to achieve, porting elisp to cl, or > rewriting core to have all those features. I don't know either, of course. I guess it depends on the feature. Some random thoughts: I'm pretty sure that CL packages could be added to Emacs as it is, if some people would work on it. I'm also pretty sure that an incremental + generational GC could be added, at least as an option, because I would have almost done it some 20+ years ago. It was torpedoed by a patent issue concerning mostly-copying GC. The patent has since expired. A lot of work, of course. I think some people do or have done something in this area, but I don't know details. I'm not at all sure that non-cooperative multi-threading could be added to Emacs. But I'm also not sure how a CL core would help here. On the other hand, I'm pretty convinced that an Emacs core written in CL would have to be close to 100% compatible with the existing C core to be accepted by users. That includes a CL rewrite of the C Elisp, including byte code interpreter. That's a massive endeavor. My hair stands up when I remember the compatibility problems I faced with the new redisplay ages ago. Multiply that by some factor > 1. But maybe that's a burnt child dreading the fire :-). I'm also not sure how a CL (not Elisp) program would look like using a CL Emacs core. Is it nice enough, so to speak? Think of Emacs strings, which couldn't be CL strings because of text properties, buffer-local variables... (Another ansatz might be to make Emacs C core a lib. I haven't given that much thought, but it could be more promising than rewriting the whole shit in CL :-).) > CFFI would also be nice to have so > that users can extend Emacs themselves with other libraries and not have to wait > for the core devs to do it for them. That would also lessen the burden on > maintaining that stuff in the core. FFI for Emacs once existed, I think Dave Love wrote one, for instance. Don't know what became of that. Might be an issue with interfacing to non-free libs.