Re: Why is Elisp slow?

[Stefan Monnier]

> I’m curious: How likely is this to happen?

As long as noone works on it, I'd say 0% likelihood.

> I can confirm that SBCL works great on at least these platforms:
> * Arch Linux(GNU userspace) on AMD64 (my friend’s confirmations)
> * macOS(Darwin) on AMD64 (I’m currently using macOS)
> * Windows 10 on AMD64 (my another friend’s confirmations)
> * Raspbian(GNU userspace) on ARM (at least when using SBCL about a year 
> before…)

[ IIUC of the 4 cases above, at most 2 run the same version, so we'd
  need to make sure the same Emacs version can be compiled against all
  of those versions.  No idea if it would impose a significant extra
  burden or not, but it's something to be considered.  Also the fact
  that the latest release doesn't work on all those platforms is rather
  worrying.  ]

>> Of course, Guile has the advantage that someone has already spent a fair
>> bit of time implementing support for Elisp, whereas for CLISP and SBCL
>> that would be extra work (Elisp is close to a subset of CL but not
>> quite).
> Would that extra work outweigh than implementing Guile’s language
> integration features?

No idea.

> May I ask what part of elisp makes implementing in CL hard?

Haven't thought too much about it, so I don't even know if it would be
hard (the elisp.lisp implementation I mentioned recently shows that
large parts can be done easily enough).
The obvious issue is buffer-local and terminal-local variables.

>> Another approach would be to implement an Elisp-to-JS compiler and
>> then use one of the heavily-optimized JIT-compilers for JS.
>> Compiling Elisp to JS should be much easier than compiling to
>> native code.
>
> If possible, this would be more than great as we would be able to use the
> *big* number of JS packages in npm registry out there.

Note that compiling to JS doesn't *directly* let you access random JS
data-structures and functions any more than implementing Elisp in C lets
you access random C functions and data-structures.
[ language-interoperation, again.  ]


        Stefan