From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Sat, 12 Aug 2023 17:58:17 +0200 Message-ID: <874jl4l0bq.fsf@dataswamp.org> References: <20230809094655.793FC18A4654@snark.thyrsus.com> <87il9owg0f.fsf@yahoo.com> <87fs4pkkqi.fsf@dataswamp.org> <87v8dk3bis.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1589"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:rNjXz3d9a1rUtbPCwdK3rPdSpUw= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 12 18:58:05 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 1qUrwD-0000Au-37 for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Aug 2023 18:58:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qUrvh-0005Dx-DJ; Sat, 12 Aug 2023 12:57:33 -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 1qUr0Y-0002QR-VF for emacs-devel@gnu.org; Sat, 12 Aug 2023 11:58:30 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUr0X-0006u7-Bc for emacs-devel@gnu.org; Sat, 12 Aug 2023 11:58:30 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qUr0V-000AP0-FP for emacs-devel@gnu.org; Sat, 12 Aug 2023 17:58:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 12 Aug 2023 12:57:32 -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:308618 Archived-At: Ihor Radchenko wrote: >> Maybe we can use SBCL to compile Elisp, and after that >> integrate it into Emacs so you would be able to run all old >> Elisp without changing the code, only now it would in fact >> be Common Lisp implementing Elisp, i.e. the opposite of our >> cl-lib (`cl-loop' etc). > > You would at least need to convert between internal object > representation in Elisp and CL. But why is CL so much faster to begin with? > Not to mention many other non-obvious problems arising from > subtle differences in the function behavior. Maybe one can fork SBCL into SBCL-E first and adapt it from there since everything that involves changing existing Elisp code, be it syntax or semantics, would be very impractical. And we are also not unhappy with Elisp as a langauge, we just want it to be faster, so what we need to do is discover and extract the secrets of compiling Lisp into really fast software, which we now have identified as being held by SBCL ... -- underground experts united https://dataswamp.org/~incal