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: Mon, 6 May 2019 14:58:48 +0200 Message-ID: <20190506125848.okei2qrib7m5p3vx@Ergus> References: <20190503103644.63lccjehmzulaojn@Ergus> <456EE4D4-F542-4F6A-B146-E6B9D72AE93B@icloud.com> <83tvebn1we.fsf@gnu.org> <20190503125832.44ovncaxp3vyjsla@Ergus> <20190504133218.g3ysx3ksuyvlthg3@Ergus> <831BD780-F954-4E23-BF31-ED4E135C919B@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="125570"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: help-gnu-emacs@gnu.org To: Stefan Monnier Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon May 06 14:59:15 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 1hNdD7-000WYO-54 for geh-help-gnu-emacs@m.gmane.org; Mon, 06 May 2019 14:59:13 +0200 Original-Received: from localhost ([127.0.0.1]:56215 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNdD6-00061q-62 for geh-help-gnu-emacs@m.gmane.org; Mon, 06 May 2019 08:59:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57443) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNdCt-00061k-77 for help-gnu-emacs@gnu.org; Mon, 06 May 2019 08:59:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hNdCr-0000yW-Th for help-gnu-emacs@gnu.org; Mon, 06 May 2019 08:58:59 -0400 Original-Received: from sonic307-53.consmr.mail.ir2.yahoo.com ([87.248.110.30]:46434) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hNdCr-0000xi-FJ for help-gnu-emacs@gnu.org; Mon, 06 May 2019 08:58:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1557147535; bh=245P77w9VOIqAPZvEqgsP/m48U6Fs4+D7CouVZU0rv8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=db/eSRGPRwzn/9/2o6fGPWq+qlO48PLJMZuHlIk4LCSi38eHbcPKjEXNi64/swU86PJCC0aN2dWTbe0VT3Gr2mS2zwG/++LMW11AC8UFjOm9yfag8S9OB/XrZyT04XrxYG5R5TW+7uHhkNVZyV3q8rPHjmTs8wo2zhCaDZonGFqFcAOr2aCMe/qSkL8i0zXTe5sDyqUWR2AjYxJqRmC1orgjpdOp+cBVmVsPQshpECxuTzG2sOTma27JsffgWLIXtyjrOLxeKA1BfV2mrpxiBNn2nrxcUOOg6NBy1JVAyL1CehEI9YaQ2NqK4MdSXn1jINSN8bSe3hRcu5T7tYYZug== X-YMail-OSG: rMdup9gVM1kuOAYaHNIxtfHHrZ3_ZNTknFGlwMseG9A9IBezj9czQ3wYYqj.RST 0H7icRGdziQeaMxZe6TvJLcC1EfgDl.OG.16IozX7dqJF0b77Z1Q9oZ6VihDDCsi0QZxKzoUfJ9q jBxCuy3TDEBtNQAy9tvz9gvLAFop2KivkHUGZnSLGH.S4hcpxOd3i8JIOPZFB3C4_Bp8Y7VgIyHB .niPUB8mNTHp9IWJhl4ZrHwlZXCuQlzR_mnq9h.jytA7p_Cs4NCFk9gr12TN8nYN2o1xcHxh3E.n Co1SR1t41coKbJrjhx9nSKvbbv.fPPjx0UC2XRnVFct2uwXvn3q5kKow_oYaGGhXNrPO8f7wxgv4 FPTLTKqI1xMpATo2sf5WQsXit7rXMOabD0ALuRFSxEDjk9N2vk_nPib12twiSJ4LQC7CNo0xCdqa OZzGQKUqYGOXtxuInB9iJWw11EK0PPy9rNM.lvjxXXz9kBAYdibdVm82UxI9ezcjT2dIyN0EQqZv ZMe55C0_5u8df2UBcjJ2EmCNdZ9UP9Qorlt4U818F67oN1p.H1qfYTmsIwn02wGAECjs8goBVcsL LzH_iMz7KPixVoqN2gCSoxNvqZBbeOhSQkpCa_in1FxdH4VWnXpMLoTLdysLoKPxBGOygij3jz2u WmJl0xyA2aGE4bPqR_U2la_lGItoagEhvwyOIoDNtN5FtnYy7cT626dvLcbAyCelWGA71bRPyDZe 3e3f1t9Fjz9dJzBUru7_FhifxoWmx9FA0Kc9e4gI2KXEyTqkiqFpaNRqjk2NydRc1KjFj.ecYYuA 2NUiu_6D6uh71pkaVdvXyZeBU4hZxUx0wtJ2lfz_au Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ir2.yahoo.com with HTTP; Mon, 6 May 2019 12:58:55 +0000 Original-Received: from 84.88.50.33 (EHLO Ergus) ([84.88.50.33]) by smtp426.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 4fd898606f446879a22963c7864f2635; Mon, 06 May 2019 12:58:52 +0000 (UTC) Content-Disposition: inline In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 87.248.110.30 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:120225 Archived-At: On Sun, May 05, 2019 at 11:50:16AM -0400, Stefan Monnier wrote: >> The more I think about Guile Emacs and the Guile project itself, I start to >> think that it???s not a problem of manpower, but something more >> fundamental. > >Quite right. > >> Is it feasible (or even possible) to make two different high >> level languages to interoperate in the engine level????? > >Language interoperation is very difficult, and even more so if you want >both languages to be usable "equally" (as opposed to a high-level >language with FFI bindings, say). The .NET platform aims to do just >that, and note that it's fairly complex and the most successful >languages there were specifically designed/tweaked for that platform. > It looks more complex because the starting point is a High level language as Lisp so any port will need many data types conversion and copies with the corresponding overheads (and ugly code). All the infrastructure is based in the Lisp Objects, types and data structures and functions. But IF the base API were designed with basic C types (int, doubles, char*) and structs, and language agnostic, the interface with Lua, Python or Ruby will be pretty simple (even Fortran, or anything else). That's what vim did and they now support many languages for extending and create plugins. (I know it is a different system and I am not saying we have to move in that direction right now.) But, instead of create lisp object from C the only we need it to create an interface for the C functions that need access from Lisp and use them in the interactive or high level lisp specific functions. But the low level functions will be all exposed in the C library and we could access then even with dlopen in some cases. Of course I am not saying that we should develop code inside emacs core with all the different languages or change language every 10 years. For me it is fine Elisp (or common lisp even better if that reduces the complexity of maintaining our on compiler and potentially improves performance). But to give the user the possibility to create plugins; a C API is much more useful and simple. And if we want to port some of those to elisp will be also easier. I specially don't share the choice of developing core parts (API) in Lisp directly because having them in C is faster, simpler, more accessible from outside if needed and usually gives less overheads to the starting time, and GC. We already have the API with the modules, but if you see most of the complexity comes from creating and converting lisp types to something else and do callbacks to lisp functions, and parsing the arguments. Defun or any other macro could be emulated if we have to, but again, that's just a complexity of making everything Lisp centric instead of C centric. Bringing a C api and use Lisp for high level or interactive functions reduces overheads, simplify the C code we have and enables a more modular design. But I know that try to do that now is not realistic with the amount of code and people we have. So that's why I was talking about Guile, but after all it seems not to be realistic either. So whats the alternative? Keep our interpreter as is and deal with few developers (and decreasing) and performance issues and a lot of code to maintain? >> For example, will it even make sense to have some Elisp macros in scheme > >Interoperation between "similar" languages like Elisp and Scheme can >probably be made to be tolerable (e.g. I guess most Emacs-specific >special forms of Elisp, such as `save-excursion`, could be provided on >the Scheme side without too much trouble (famous last words)), but >macros seem pretty hard to handle in general (i.e. will require manual >work on a macro-by-macro case). > >> land, or even lua land, python land, JS land????? > >For these, macros aren't the only problem, since there's also the >problem of the different kinds of datatypes used. What would JS objects >look like in Elisp, and what would Elisp objects look like in JS? > >> I would like a JSish API for emacs when writing packages, not a low >> level wrapper around Elisp APIs. > >Indeed. > >> What would I do to use a Python module in JS????? Unless the language itself is >> designed to be easily interoperable with elisp by superseding concepts (such >> as Clojure superseding Java), I???m pretty sure many people won???t be satisfied >> in any kind of implementation. > >Exactly. > > > Stefan > >