From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?7KGw7ISx67mI?= Newsgroups: gmane.emacs.help Subject: Re: Why is Elisp slow? Date: Fri, 3 May 2019 22:16:32 +0900 Message-ID: <96FA6D13-0AEF-4353-9736-8E56195AD0E2@icloud.com> 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> <20190503125132.xyats445fsthdw7l@Ergus> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="14572"; mail-complaints-to="usenet@blaine.gmane.org" Cc: help-gnu-emacs@gnu.org To: Ergus Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri May 03 23:18:22 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 1hMfZI-0012u5-OP for geh-help-gnu-emacs@m.gmane.org; Fri, 03 May 2019 23:18:08 +0200 Original-Received: from localhost ([127.0.0.1]:40676 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMY3c-0005Zs-Nw for geh-help-gnu-emacs@m.gmane.org; Fri, 03 May 2019 09:16:56 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMY3O-0005Z9-Nz for help-gnu-emacs@gnu.org; Fri, 03 May 2019 09:16:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMY3N-0000ZO-Ac for help-gnu-emacs@gnu.org; Fri, 03 May 2019 09:16:42 -0400 Original-Received: from pv50p00im-ztdg10021201.me.com ([17.58.6.45]:49729) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hMY3N-0000YR-2U for help-gnu-emacs@gnu.org; Fri, 03 May 2019 09:16:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1556889399; bh=Akzh6aBHH+xlk1L0M0Aot32t6r4RNiyCz29CZMGZLYI=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=hmisP0zrVguccj9PIVhtelfDFMjuhGo4SIvkg9p+6ZkShlMUCmaA1hrXXzxquhjB9 hTgHDbPV8v1dk3qnF/G0u9PjyRSyCWTrw1iAnb5Pckq7H7tWgBWTUoOgshFT2UPtDF /1F3jplh2sjPTYBMyfHOeS1rrJloWl5wuZtEcLZQjK7UfhfCs4nL/XFptInYHZN5bQ KbYVr/qoE5OrG8etG0VG/PpmABCsrjPoaarK7XwC26m2+9+90izVUhDAUob0tW3trl wIaqMBKHacU3GuAWdr9Of7Fv2CIPtMw616sTm5Pz98IZiZM5u2M3RGUepY5Kcv4Ij9 m0zhQ+Vs2D5zw== Original-Received: from [10.42.236.95] (unknown [14.63.1.106]) by pv50p00im-ztdg10021201.me.com (Postfix) with ESMTPSA id 37B44A40105; Fri, 3 May 2019 13:16:35 +0000 (UTC) In-Reply-To: <20190503125132.xyats445fsthdw7l@Ergus> X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-03_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1905030084 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 17.58.6.45 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:120162 Archived-At: Looks like the point of getting Guile Emacs recurs to: * How much Guile Emacs is polished(seamless integration with Elisp, full = compatibility, etc..) * How much Guile supports other languages such as JS or Lua * How much Guile manages to be fast Guile Emacs was developed for at least 15 years or more, right? How much can Guile Emacs do these in current situation?=CC=8A=CC=88 Is Guile Emacs usable day-to-day? > 2019. 5. 3. =EC=98=A4=ED=9B=84 9:51, Ergus =EC=9E=91=EC= =84=B1: >=20 > On Fri, May 03, 2019 at 08:52:06PM +0900, =EC=A1=B0=EC=84=B1=EB=B9=88 = wrote: >=20 >> 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 more popular than Guile, and is used by = industry-strength programs. >=20 >> * 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. >=20 > 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. >=20 >> * I'm pretty sure CL will be much, much faster than Guile. >=20 > Probably, that depends of the compiler not only the language. >=20 >> 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 >=20 >>> https://www.gnu.org/gnu/rms-lisp.en.html = >>=20 >> I read the link; it's a pity to not consider CL because it isn't = "lispy" enough. >>=20 >>>=20 >>>> IMHO building emacs on CL would be a wonderful idea... and would = fix many problems that current Emacs have. >>>>=20 >>> And create others, it is always a trade off. >>=20 >> What problems would CL based Emacs can make? Can you show some = examples? I am genuinely interested. >>=20 >=20 > 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. >=20 >>>=20 >>> Any way >>>=20 >>> 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. >>=20 >> Well, CL is as fast as C. >=20 > 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. >=20 > 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). >=20 > Think also in the licenses issues and legal consequences of such = strong > dependency for a key part of the editor. >=20 > 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. >=20 > 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.