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: Mon, 6 May 2019 22:18:59 +0900 Message-ID: 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> <20190506125848.okei2qrib7m5p3vx@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="255506"; mail-complaints-to="usenet@blaine.gmane.org" Cc: help-gnu-emacs@gnu.org, Stefan Monnier To: Ergus Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon May 06 15:28:45 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 1hNdff-0014DZ-65 for geh-help-gnu-emacs@m.gmane.org; Mon, 06 May 2019 15:28:43 +0200 Original-Received: from localhost ([127.0.0.1]:56634 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNdfZ-0003mT-2d for geh-help-gnu-emacs@m.gmane.org; Mon, 06 May 2019 09:28:37 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNdWM-0004xZ-Pa for help-gnu-emacs@gnu.org; Mon, 06 May 2019 09:19:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hNdWL-0001bA-4H for help-gnu-emacs@gnu.org; Mon, 06 May 2019 09:19:06 -0400 Original-Received: from pv50p00im-zteg10021301.me.com ([17.58.6.46]:42956) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hNdWK-0001ar-Se for help-gnu-emacs@gnu.org; Mon, 06 May 2019 09:19:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1557148743; bh=R831CZrAvgijJqZDp01g5qNXtnValU9XejS0XlVpnNM=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=e1rxhb74lvnFIq3CFxeq4pi9fdeLjPxZXN3HWSvPzAdJoWsM5Y9UVbmtdq8PC7bEi 9yqbSzQp7hK01NQMxYBn5VrodTGQnJQa9jwfzekY6yxKKgycufETxvy1OPU3R61Pku xiKFwsdnf6Ijz96EZmVq3D/W8JmoFzf4A9suv/+QKvHV44LenmrEOZRTB39z27XViR hFj5HInCYUpnEgzihxbEUVLRBeEcNE+dWIdwZUile617jj8/wqwC37vrQIf4jsNpbo UV8jtMaam4EInXU894F4pVPv1ubxvzFFRHlso4X3jLaQFFOLatWtBfHIbGOt4cuLet xhW8AblRc6r5A== Original-Received: from [192.168.0.156] (unknown [115.93.75.204]) by pv50p00im-zteg10021301.me.com (Postfix) with ESMTPSA id 57FB9580A41; Mon, 6 May 2019 13:19:02 +0000 (UTC) In-Reply-To: <20190506125848.okei2qrib7m5p3vx@Ergus> X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-06_09:, , 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=352 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1905060116 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 17.58.6.46 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:120227 Archived-At: (As I am not currently familiar with how the Emacs codebase is = structured) How does Emacs do FFI currently? If I recall correctly = aren=E2=80=99t there ways to call C functions in elisp? Would it be hard = to expose C functions (by compiling to the SysV ABI) and calling them in = elisp (to write plugins in another language)? If I understand the = current architecture of Vim correctly, Vim is also doing that; it=E2=80=99= s impossible to not use VimScript to make plugins, glue code is = essential. > 2019. 5. 6. =EC=98=A4=ED=9B=84 9:58, Ergus =EC=9E=91=EC= =84=B1: >=20 > 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. >>=20 >> Quite right. >>=20 >>> Is it feasible (or even possible) to make two different high >>> level languages to interoperate in the engine level????? >>=20 >> 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. >>=20 > 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). >=20 > 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). >=20 > 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.) >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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.=20 > 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. >=20 > 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? >=20 >=20 >=20 >=20 >>> For example, will it even make sense to have some Elisp macros in = scheme >>=20 >> 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). >>=20 >>> land, or even lua land, python land, JS land????? >>=20 >> 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? >>=20 >>> I would like a JSish API for emacs when writing packages, not a low >>> level wrapper around Elisp APIs. >>=20 >> Indeed. >>=20 >>> 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. >>=20 >> Exactly. >>=20 >>=20 >> Stefan >>=20 >>=20 >=20