Re: Why is Elisp slow?

[조성빈]

> 2019. 5. 7. 오전 2:25, Stefan Monnier <monnier@iro.umontreal.ca> 작성:
> 
> I totally agree with the sentiment; we'd benefit from "out-sourcing" the
> maintenance of the language implementation, but we can't just replace
> Elisp with something else, so we need to find another well-maintained
> Elisp implementation that's at least as good as that we have now.

I’m curious: How likely is this to happen? This would be truly great if 
happening :-) 

> AFAIK the options are:
> - Keep what we have
> - Move to Guile
> - Move to CLISP
> - Move to SBCL
> CLISP is not actively maintained nowadays.
> AFAIK SBCL is alive and kicking, but I'm not sure how well it works on
> platforms other than GNU/Linux-on-AMD64.

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…)

CCL is similar (actually provides more support on non-GNU platforms).

> 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?
Perhaps an insightful person may know?
May I ask what part of elisp makes implementing in CL hard?

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

> 
>        Stefan
>