4 ms·
I would expect that an ELisp interpreter written in Common Lisp would likely be slower than the existing ELisp interpreter written in C. As for compilation to
by ufo 7y ago
I would expect that an ELisp interpreter written in Common Lisp would likely be slower than the existing ELisp interpreter written in C.
As for compilation to Common Lisp, I don't know how feasible it would be. Apparently they tried something similar with Guile and it ran into problems.
- bjoli 7y agoGuile (the VM) runs elisp just fine. There has been zero optimization work done though so it is quite slow. The reason they did not go with guile was more political than anything else. It was also understandable from their point of view (and I say this as a guile weenie)
- rurban 7y agoNo, the reason is still slow string buffers. Politically everybody wants emacs to switch to guile.
- bjoli 7y agoIirc Guile-emacs relies on Emacs for all string related functionality. The overhead comes for dynamic bindings that are currently slower in guiles elisp implementation. I haven't looked into it since talking to Robin about it in 2016. You maybe have some more inside info, but back in 2016 I remember a lot of complaints and that guile was a liability for the much bigger Emacs project. Maybe even people threatening to retire as maintainers
- hvis 7y agoIt was somewhat political, but it was more of an issue of manpower. Also, Guile is basically maintained by one developer (as far as I've heard). It's pretty dangerous for Emacs to rely on a project like that.