We have a macro expander for pascal written in scheme (quick and dirty draft made by me that worked so well it stayed). We had some performance problems with some crazy recursive macros (it generates a _lot_ of code. Don't ask, I am not allowed to talk much about it), so I investigated porting it to chez.
Instead I just switched to guile (scheme implementation) trunk and got a 3x speedup. Did some optimizing work and it ended up at 4x, which is good enough.
The Guile 2.0 branch. I don't know what magic optimisation dust they sprinkled over the upcoming 2.2, but it sure is fast.
We thought about using chicken, but it depends quite a lot on using syntax-case to deconstruct everything, and I didn't want to learn their implicit renaming stuff.
Apparently the 2.2 branch has full elisp support. Can't wait for Emacs to run on it.
Ah, that makes sense! Guile 2.2 has a completely rewritten compiler and virtual machine. I'm happy to see some real-world instances of it greatly improving performance.
"greatly improving performance" is an understatement! It was literally 3x. I didn't even have to change anything. Not bad for a language that usually beats python by quite a large margin :)
> Apparently the [guile] 2.2 branch has full elisp support. Can't wait for Emacs to run on it.
I really wish folks would spend the time they spent porting elisp to guile Scheme porting elisp to Lisp instead. Scheme's great for what it is (really), but what it is not is an industrial-strength systems programming language. Common Lisp is.
This is a common misunderstanding. Emacs Lisp is not being rewritten as Scheme. What is actually happening is that there is a compiler for Emacs Lisp that runs on Guile's virtual machine. Elisp isn't going anywhere.
I'm not that familiar with guile internals, but IIRC they have some intermediate representation (bytecode?) that the VM then runs. So the frontend languages (Scheme, Elisp, even Javascript IIRC) are compiled to bytecode, the Guile VM then interprets the bytecode.
