From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.help Subject: Re: Why is Elisp slow? Date: Fri, 3 May 2019 14:51:32 +0200 Message-ID: <20190503125132.xyats445fsthdw7l@Ergus> References: <87woj8bqho.fsf@telefonica.net> <83tvecocvv.fsf@gnu.org> <87sgtwboot.fsf@telefonica.net> <83muk4obfd.fsf@gnu.org> <20190502214006.4fdsinp7u5xuqvdv@Ergus> <20190503004416.xfuzzucflp6bxpuz@Ergus> <20190503103644.63lccjehmzulaojn@Ergus> <456EE4D4-F542-4F6A-B146-E6B9D72AE93B@icloud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="16379"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: help-gnu-emacs@gnu.org To: =?utf-8?B?7KGw7ISx67mI?= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri May 03 23:18:35 2019 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hMfZS-0012u5-6w for geh-help-gnu-emacs@m.gmane.org; Fri, 03 May 2019 23:18:18 +0200 Original-Received: from localhost ([127.0.0.1]:40323 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMXfM-0000ED-0p for geh-help-gnu-emacs@m.gmane.org; Fri, 03 May 2019 08:51:52 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMXfB-0000E6-Oy for help-gnu-emacs@gnu.org; Fri, 03 May 2019 08:51:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMXfA-0008Nj-Gk for help-gnu-emacs@gnu.org; Fri, 03 May 2019 08:51:41 -0400 Original-Received: from sonic305-20.consmr.mail.ir2.yahoo.com ([77.238.177.82]:33625) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hMXfA-0008Mz-0v for help-gnu-emacs@gnu.org; Fri, 03 May 2019 08:51:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1556887897; bh=0w9g6kaHLT4FyWhL119yZai5FXzX/QurlC3Wzl0pJ9Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=n8uXhk69M2U7Gqd0ncOxmrF991jBXT9nk5iDb1lWzVPQfwHUcuWDCy5Va93ELrv9QXidcsp36/niPJNsNWSTXNNqS1rbekZZDuYgiloROWzPWJQjUZB6ZIjcSkfCXNFE5OyGkLNQjUvFgtaiatHdNoY1sX0rCGMPbC0CPDU9R//HUm6/igJ3snO4qAEapZKWLULMbjc53gZoYGzl7+mMEFTF+g9VHzzZIsfrmvprHF4r4X98zJcl5CBzxPY+U1gyNaGcMJRCZCnDuAhwhRUxl/28ofsizG54YbEee1Iuv9lfWcB6EcW7zeF/JDIwUVQZLkXseFd6KaVRccXe+N7GUg== X-YMail-OSG: TYgPoI8VM1l6P9u5A5_VG0W9GzfDR9DP.g7w_9JbHZQe__1Ow24yHUIF972dv8n pu7O0EZsPeRo1mnEtOPyUPDY5fLL4JgjgHbm_BE58b2MoV5N6nMHcf24HfIGGSsmysESthPti6Xd 9KpDEMGtTTOPD3_PIOpKftXk8_CR.Pe_IBttgvaxewEjIWbeq.nstVLAvapY.9qpSvrkApdLfjLu .JEWrFt.dwgPkRIIufkHC6BejYedPWHdyVY6iclW4kyaaOxK4fPHloKHgBxtZvPyy_VSj2XzOG6T nP8UOABwBhkOz_ZxHDAcg5lgBDb1tIf7xhCqTJkHbukd_sKPjgjvGnOOLREJ1aQZ4xQ8M.pz59E. s2BffJD30UYb6AdO4utLuHglWEajkBv0MPdeK3bX3zxUVsYdR1hvSnbg5u_lUa.W8tFPSo1pvZ8n 1uS_f04WFCrVs1CYF6WlIkKJodrfDOn.Q97QQrOHfx.kTkttbhqIZMjv8LBaqDY45_4W2cTKH.ip Oyi37P0smJp8jwg4z0NWBpWFYupsszpISQtpv7BQHh_Vh1lyhaTNSdZTjkJI4IEK6jsRDnfWOD1L 9V8vkApKESbiAW8kGHPeLSZ_gr.Jx0hN6BYDFnSvFcqyGwJoX0qLuGILBJX0ef5XVeGgQIUZQLhx 5Ou7OLCVeO3LQrIT7p4o3DXzkIAgJUFPgadjSBFShZaZfIQdKVkpK6vEcdAEiSL9DDf.Nidpx1gx 2gxYgSVX3j_8JrxfQsQrMjWjvLD0UByUcGOzfxmYaQUDSHqZy3hAlS1GTLcSWphUkoLWvIy6rkgh Q0OXwD66MgnHARgAhPV3_FTdbPBquUsWIH05xJsQQM Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ir2.yahoo.com with HTTP; Fri, 3 May 2019 12:51:37 +0000 Original-Received: from 84.88.50.33 (EHLO Ergus) ([84.88.50.33]) by smtp423.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 068eb585415d4a6669383cecbd834228; Fri, 03 May 2019 12:51:35 +0000 (UTC) Content-Disposition: inline In-Reply-To: <456EE4D4-F542-4F6A-B146-E6B9D72AE93B@icloud.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.238.177.82 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:120166 Archived-At: On Fri, May 03, 2019 at 08:52:06PM +0900, ????????? wrote: > > >The difference between guile and CL is that * Guile is arguably not >popular and not used by many programs.I???ve never heard a program that >is popular and uses guile as an extension language. CL is, well, much >popular than Guile, and is used by industry-strength programs. > * Guile (which is a scheme) has a radically different syntax with >elisp (which means that to implement elisp in guile, one has to hack >the byte code interpreter AFAIK). Elisp can be implemented inside CL >with full compatibility, which mitigates lots of problems between >interfacing between CL code and elisp code. But guile is in fact developed in the gnu project, so there are the guile developers (very few but they are) that could potentially provide and fix any issue. But also the strong part of guile is not the language itself but the potential of the infrastructure. >* I???m pretty sure CL will be much, much faster than guile. Probably, that depends of the compiler not only the language. >CL was optimized for about 30 years or so, and SBCL compiles CL all the way to native code, which is comparable to C. I???m not sure if guile can do that. > Guile has been also optimized (in spite of there is a lot of work to do, that's true) and yes, it can generate native code, but also bytecode. But it also offers a lot of functionalities to extend and work as a glue language which is actually most important in our days. At the end (in my opinion) if emacs wants to survive other 40 years it will need to start looking for integration with python, lua, C++, rust, Ruby and similar languages with a more "promising" future than common lisp. Because we really need to attract new developers with new ideas, visions and experiences... and 99% of programmers don't use any lisp like language. To make big changes we need more developers, that will not come if we don't have more users first. And those new users/developers can enforce the new changes looking at the future and not to backward compatibility. >> https://www.gnu.org/gnu/rms-lisp.en.html > >I read the link; it???s a pity to not consider CL because it isn???t ???lispy??? enough. > >> >>> IMHO building emacs on CL would be a wonderful idea... and would fix many problems that current Emacs have. >>> >> And create others, it is always a trade off. > >What problems would CL based Emacs can make????? Can you show some examples????? I am genuinely interested. > Dynamic scoping rules vs exical scoping rules in common lisp is just the first one I can remember, but maybe someone else will reply you with more details. >> >> Any way >> >> I have to say that comparing to other interpreters around the Elisp is >> not the slowest one I have tried by far. Of course it could be way >> faster, but some optimization like user code and provide new containers >> and datatypes in the library level based in C (and recomend them) code >> could potentially make more difference in real user extensions. > >Well, CL is as fast as C???. > But again, common lisp is just a language. Performance is more associated with the compiler you use. Cython makes python very fast too for example AND IT IS PYTHON!!!. The latest version of the GNU common lisp compiler (GCL) was in 2014... so its developement goes slower than Guile. If we had a native compiler for Elisp it could be as fast as common lisp (ideally). But in any case it needs to be something that goes embedded within emacs (otherwise emacs won't be emacs anymore). Think also in the licenses issues and legal consequences of such strong dependency for a key part of the editor. On the other hand it is true that in that case that will be a part of the code that we won't need to maintain if we rely on other packages. Let me say something. I am not opposed at all to switch to common lisp, (or scheme or python, actually I think that at some point it will be needed to change the core language for something more flexible) what I mean is that this specific problem is not a language issue, but the compiler. And I don't think that we can just copy the SBCL code into emacs for many reasons.