3 ms·

I hope Emacs guys will finish the GuileEmacs[1] project. They listed 3 main advantages: "The first immediate advantage is that Elisp will execute faster, beca

by xvilka 10y ago

I hope Emacs guys will finish the GuileEmacs[1] project. They listed 3 main advantages: "The first immediate advantage is that Elisp will execute faster, because Guile uses a compiler tower with many optimization passes and ultimately compiles to Guile VM bytecode, which is more efficient than current Elisp bytecode. In the future, Guile is likely to implement some forms of native JIT as well as AOT compilation as well. 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. 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. C-implemented functions (“subrs” in Elisp terminology), Elisp functions, Scheme procedures, etc. all compile to the same “procedure” data type, which may appear in Elisp symbols’ function-slots, be bound to Scheme variables, and are otherwise first-class objects in both environments which can be funcalled or applied explicitly or by the language’s normal syntactic way of calling functions. Similarly, other data types are unified between the languages; Elisp integers and exact Scheme integers, inexact Scheme numbers and Elisp floats, Elisp cons cells and Scheme pairs, symbols, etc. are the same data type across the languages. (Strings are an exception though; see below.) Therefore one can generally use a library written in another language as if it were written in the same language." And looks like there is some progress still: [2] Here is the current TODO list [3], if someone wants to help. [1] https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs [2] https://lists.gnu.org/archive/html/guile-devel/2016-03/msg00028.html https://lists.gnu.org/archive/html/guile-devel/2016-03/msg00... [3] https://www.emacswiki.org/emacs/GuileEmacsTodo https://www.emacswiki.org/emacs/GuileEmacsTodo

wtbob 10y ago
> 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.
- jpfr 10y ago
  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.
  - wtbob 10y ago
    > 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.

by xvilka 10y ago

wtbob 10y ago

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

jpfr 10y ago
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.
- wtbob 10y ago
  > 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.