[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why is Elisp slow?

From: Stefan Monnier
Subject: Re: Why is Elisp slow?
Date: Sun, 05 May 2019 11:50:16 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> 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.

> 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.


> 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. 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]