> I hope Emacs guys will finish the GuileEmacs[1] project.
I really really hope they don't and use Common Lisp to achieve the same end. Running emacs in a Common Lisp like SBCL implementation means that it will be natively compiled, with an extremely intelligent compiler.
> A second advantage is that it will be easier to implement some additional language features for Elisp which the Guile compiler tower and VM are capable of, like a full numeric tower (infinite-sized integers, exact rational numbers, imaginary numbers, etc.), record types (like an improved defstruct), CLOS-like OOP, an FFI, composable continuations, a module system, hygienic macros, multiple-value returns, and threads.
Common Lisp has infinite-sized integers, exact rational numbers and imaginary numbers. It has DEFSTRUCT. It has CLOS (obviously). Every Unix Lisp I'm aware of has an FFI. Continuations are actually a problem when it comes to e.g. UNWIND-PROTECT. Common Lisp has packages and an excellent module system in ASDF3. It has hygienic macro libraries, and natively supports the more-powerful DEFMACRO. It supports multiple-value returns. BORDEAUX-THREADS is an excellent portable thread library.
> A third advantage is all Guile APIs/libraries becoming available to Elisp code, no matter what language they’re implemented in, because different languages on the Guile VM can inter-operate quite well, especially if they’re both a Lisp.
Common Lisp has many excellent libraries available via Quicklisp.
Scheme is IMHO a broken language: distinguishing NIL and #f; only have one namespace; continuations; not allowing (cdr nil); not having a native object system; not having a rich type and class library; not having read macros. It was an interesting experiment, but the effort spent on Schemes would have been better spent improving Lisp.
Lisp is far closer to elisp, and is a better language to boot.
> The idea of GuileEmacs is not to move away from the elisp language. The idea is to use an elisp implementation based on the Guile virtual machine.
> Elisp will not go away. So any arguments for lisp and against scheme are void in this context.
If the goal is not to mingle elisp & Scheme, then what's the point of using the Guile VM? Why not just implement an interpreter for elisp in Lisp?
There is absolutely no reason to mingle Scheme with elisp. Scheme's not a bad language for those places it's well-suited, but production software is not one of those places. For that there is Common Lisp.
I really really hope they don't and use Common Lisp to achieve the same end. Running emacs in a Common Lisp like SBCL implementation means that it will be natively compiled, with an extremely intelligent compiler.
> A second advantage is that it will be easier to implement some additional language features for Elisp which the Guile compiler tower and VM are capable of, like a full numeric tower (infinite-sized integers, exact rational numbers, imaginary numbers, etc.), record types (like an improved defstruct), CLOS-like OOP, an FFI, composable continuations, a module system, hygienic macros, multiple-value returns, and threads.
Common Lisp has infinite-sized integers, exact rational numbers and imaginary numbers. It has DEFSTRUCT. It has CLOS (obviously). Every Unix Lisp I'm aware of has an FFI. Continuations are actually a problem when it comes to e.g. UNWIND-PROTECT. Common Lisp has packages and an excellent module system in ASDF3. It has hygienic macro libraries, and natively supports the more-powerful DEFMACRO. It supports multiple-value returns. BORDEAUX-THREADS is an excellent portable thread library.
> A third advantage is all Guile APIs/libraries becoming available to Elisp code, no matter what language they’re implemented in, because different languages on the Guile VM can inter-operate quite well, especially if they’re both a Lisp.
Common Lisp has many excellent libraries available via Quicklisp.
Scheme is IMHO a broken language: distinguishing NIL and #f; only have one namespace; continuations; not allowing (cdr nil); not having a native object system; not having a rich type and class library; not having read macros. It was an interesting experiment, but the effort spent on Schemes would have been better spent improving Lisp.
Lisp is far closer to elisp, and is a better language to boot.