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 10:06:56 +0900 Message-ID: References: <20190502075617.GA18331@tuxteam.de> <874l6d3ylg.fsf@mbork.pl> <20190502131827.GA28987@tuxteam.de> <83k1f8q39o.fsf@gnu.org> <87woj8bqho.fsf@telefonica.net> <83tvecocvv.fsf@gnu.org> <87sgtwboot.fsf@telefonica.net> <83muk4obfd.fsf@gnu.org> <20190502214006.4fdsinp7u5xuqvdv@Ergus> <20190503004416.xfuzzucflp6bxpuz@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="205929"; 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 03:07:29 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 1hMMfh-000rPb-44 for geh-help-gnu-emacs@m.gmane.org; Fri, 03 May 2019 03:07:29 +0200 Original-Received: from localhost ([127.0.0.1]:60820 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMMff-0005Kr-Vz for geh-help-gnu-emacs@m.gmane.org; Thu, 02 May 2019 21:07:28 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43372) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMMfS-0005Ij-Hd for help-gnu-emacs@gnu.org; Thu, 02 May 2019 21:07:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMMfO-0003Iu-Qz for help-gnu-emacs@gnu.org; Thu, 02 May 2019 21:07:14 -0400 Original-Received: from mr85p00im-ztdg06011101.me.com ([17.58.23.185]:41041) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hMMfJ-0003Df-Cp for help-gnu-emacs@gnu.org; Thu, 02 May 2019 21:07:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1556845620; bh=yCP6/8Jy5qpFvcsJQUqZsL+IUrSY6y/lAYarzBo8DMg=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=UUtE3JlnOl22eEiccivMvvLiZPXHt22XTGT9rDnnu4O7QKHusZ/zRw2XufMme3nzx G09jl2LLkHuYDeKRNzUZo985ezBmpDWVkZdVnT+aX/SS0au/jQQ6skxlhJk3s/fMCl T3svEWb7YKtfeV6zZNf/v1FfRDqIW6xcDtY7uIukZlIU96U+mozEnlo7KZoJ14gLFU 35/BF6+v+y7PHSyyPAWS/h16owQQYtdQTyf/WbhG+SL1H0kPg9vOUCWt8mejKCiyTz dpIbivOUyrLeGrxM6xcSzUlIEgtkGcD0aQRVVGmnW9h+Fv4V8MCVw0hHynqv9dv8YI 1rzL3uGmCvFhA== Original-Received: from [10.36.63.94] (unknown [223.62.212.177]) by mr85p00im-ztdg06011101.me.com (Postfix) with ESMTPSA id 619864A02A3; Fri, 3 May 2019 01:06:59 +0000 (UTC) X-Apple-Base-Url: x-msg://4/ X-Universally-Unique-Identifier: 9D38488A-AEC3-4AD5-920D-F7CCA406FDE0 X-Apple-Mail-Remote-Attachments: YES X-Apple-Auto-Saved: 1 X-Mailer: iPhone Mail (16E227) In-Reply-To: <20190503004416.xfuzzucflp6bxpuz@Ergus> X-Apple-Windows-Friendly: 1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-02_13:, , 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-1905030005 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 17.58.23.185 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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:120146 Archived-At: I became curious after reading your email :-) Since implementing a new language/byte interpreter (Guile, for example) is h= ard, and making it fast is harder, why doesn't Emacs leverage the Common Lis= p environment?=CC=8A=CC=88 For example, (since CL and elisp=E2=80=99s syntax is mostly similar) can=E2=80= =99t we implement Emacs based on CL (looks like there were ongoing efforts b= efore like Climacs, Hemlock, etc=E2=80=A6) and expose elisp functions in a s= pecial package named =E2=80=98elisp=E2=80=99?=CC=8A=CC=88 It would allow eli= sp compatibility (by running all elisp code in the special elisp package) wh= ile giving package writers access to CL libraries. Since legacy cruft can go= inside the package =E2=80=98elisp=E2=80=99, CL emacs APIs can remove/redesi= gn some old APIs and remove technical debt. This would also greatly accerlat= e Emacs speed as CL is super fast especially when using with SBCL. Are there any reasons (that I do not know) why CL was not considered or was c= onsidered but rejected as an elisp alternative?=20 Are there license problems to build on previous attempts?=CC=8A=CC=88=20 IMHO building emacs on CL would be a wonderful idea... and would fix many pr= oblems that current Emacs have. > 2019. 5. 3. =EC=98=A4=EC=A0=84 9:44, Ergus =EC=9E=91=EC= =84=B1: >=20 > WARNING: This email has plenty of personal opinions. >=20 >> On Fri, May 03, 2019 at 08:39:43AM +0900, ????????? wrote: >>=20 >>> Probably (I have a dream) if someone decides to develop a new emacs in >>> 2019 most of the functions and API will be made in pure and clear C (or >>> any other compiled language), with a full C api that gives the same >>> access level than what elisp gives in Emacs today (with C lists, arrays >>> and structs), so it will be not only faster but also simpler to extend >>> it with other languages like Scheme, Python, Lua, C++, rust and so >>> on. (There are modules projects going in that direction) And the editor >>> don't even need to provide a compiler or interpreter for them. (there >>> will be Guile/gcc/python and so on for that) >>=20 >> This, very much sounds like Guile Emacs. Anyone knows how Guile Emacs >> is doing????? It???s very much looks like vaporware these days :-( >=20 > Yes, that is the dream (at least the closest we have ever been) >=20 >> Is upstream considering Guile Emacs as a valid solution? >=20 > I made a similar question some time ago and the answer is that there is > not action. :( In fact there is not too much action in > Guile's development . >=20 > Not many projects feel interested in Guile because the weak support it > has so there are few users and few developers (But also because > Lisp-like family languages (common Lisp, Scheme and the others) are a > museum piece for young generations that are more used to Python, Ruby, > javascript, and most of OOP (also because there are more jobs with > that)) >=20 > Actually I think that these days will be easier to find new C/C++ > developers for emacs than Lisp developers. Lisp and Scheme are > beautiful, but they require a different way of thinking and a lot of > time (own experience, I am just starting with it.) One reason why I > can't convince my friends to use Emacs is actually how Lisp scares them > ((())()'()). >=20 >> Is there any development ongoing? (Official or not?) > I don't think so :( :( :(. It will require that some core emacs > developers feel more interested in implementing this, because it is a > lot of work... (specially to do it right and keeping the so sacred > backward compatibility) These days only few people know the core parts > of emacs for such a task. >=20 > Having Guile as a dependency will grow emacs size significantly > and using it as an external dependency (not usually the emacs way...) > will require to port Guile to more systems (AFAIK). BUt such desition > could benefit very much both projects. >=20 > There are even some emacs ports to rust (remacs) but they still have the > elisp as the core languaje. Because most of the code and functionalities > are already in elisp so changing that will be like reimplementing all > emacs from scratch. >=20 > (Some time ago there was a lot of effort and time invested in porting C > functions to Elisp in emacs) >=20 > So with our actual emacs maybe the JIT or the Lisp->C source to source > is actually the more reliable option in a possible (realistic) future. >=20 > Personally I feel the Lisp->C compiler feels like the faster and more > robust solution for me, but it will create a dependency with > binutils... which is for multiple reasons undesired. >=20 > The alternative JIT may be based in libJIT which is not very active > either... and has serious issues/limitations that has not been solved in > years. >=20 > [1] https://tromey.com/blog/?p=3D982 > [2] https://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00393.html