Guile is almost 30 years old. It’s GNU’s Scheme implementation. People wanted to replace the nonstandard Emacs Lisp with Scheme but since so much code was written in elisp, they didn’t want to throw it out. At this point someone should abstract out the Emacs definition so others could build it with Scheme or Clojure. Emacs is basically a Lisp interpreter. They wrote the parts that needed to be fast in C and the rest…
It's true that Guile is a Scheme implementation, but it is also a platform to host any other language. The Guile-Emacs project wasn't about removing Elisp, it was about making Elisp run on the Guile VM.
Guile is almost 30 years old. It’s GNU’s Scheme implementation. People wanted to replace the nonstandard Emacs Lisp with Scheme but since so much code was written in elisp, they didn’t want to throw it out. At this point someone should abstract out the Emacs definition so others could build it with Scheme or Clojure. Emacs is basically a Lisp interpreter. They wrote the parts that needed to be fast in C and the rest…
I sometimes feel that someone needs to declare "elisp bankruptcy" in the same vein as one declares inbox bankruptcy, accept that implementing all of elisp in another superior lisp is too much work, write a better emacs-alike from the ground up in a proper, performant lisp, and let the package authors do the work of porting their packages.
Guile is almost 30 years old. It’s GNU’s Scheme implementation. People wanted to replace the nonstandard Emacs Lisp with Scheme but since so much code was written in elisp, they didn’t want to throw it out. At this point someone should abstract out the Emacs definition so others could build it with Scheme or Clojure. Emacs is basically a Lisp interpreter. They wrote the parts that needed to be fast in C and the rest…
It's true that Guile is a Scheme implementation, but it is also a platform to host any other language. The Guile-Emacs project wasn't about removing Elisp, it was about making Elisp run on the Guile VM.
Yes, that’s what I meant. They don’t want to throw away the Elisp but they want to support a Scheme.
Someday in the far far future long after Scheme is supported and millions of lines is rewritten in Scheme, I could imagine dropping support for Elisp.
Then Emacs will be nothing more than a large Scheme program that could run on any implementation of Scheme
Well, one of the major points of Guile (speed) is becoming obsolete as people are working in native-compiling elisp with libgccjit[0]. It provides great speed benefits: an average of x3~4 and up to ~x20 on recursive functions. With type annotations we can speed it up more — no need for a Guile JIT for speed anymore. [0]: https://akrl.sdf.org/gccemacs.html
Guile-Emacs was making a larger point about GNU: What if instead of each application being its own island, there was more of a shared infrastructure? A text editor (or any other GNU application) shouldn't have to concern itself with programming language implementation, they should be able to focus on their problem domain. GNU devs could use Guile as a solid base for user-extensible programs (something GNU as a whole is supposed to value, but in practice mostly doesn't except for Emacs and a few others.) I don't think this will ever happen because GNU lacks cohesive vision and leadership, but Guile-Emacs was a worthy experiment anyway. There is one success story in GNU, though: Guix. That project has demonstrated the mutually beneficial relationship that other GNU projects could have with Guile if they ever wanted to go that route.
It's true that Guile is a Scheme implementation, but it is also a platform to host any other language. The Guile-Emacs project wasn't about removing Elisp, it was about making Elisp run on the Guile VM.
Yes, that’s what I meant. They don’t want to throw away the Elisp but they want to support a Scheme. Someday in the far far future long after Scheme is supported and millions of lines is rewritten in Scheme, I could imagine dropping support for Elisp. Then Emacs will be nothing more than a large Scheme program that could run on any implementation of Scheme
I think it's easier to port everything elisp to Scheme (with some help by automation perhaps), than having an Emacs implementation in a Scheme that runs in all implementation of Scheme. I've worked many years in Scheme and the differences between compilers and interpreters are too large, especially when it comes to low-level functionality necessary for good performance.
> Most surprising is the abysmal speed of the test[4], I’m looking forward to anyone being able to explain that part to me. Just a shot in the dark, but I think since so many tests are failing, all bets are off as to their performance. For example, I could see a test getting into a loop that normally only runs ten times and succeeds, but here gets to run a million times before the test aborts and gives up. Not sure t…
The tests don’t do anything interesting. You can see the code to generate the tests in the article. All the tests do is see whether each symbol (from whatever symbols the author had when they started emacs) is defined in the environment and, if so, that’s a pass.
Guile is almost 30 years old. It’s GNU’s Scheme implementation. People wanted to replace the nonstandard Emacs Lisp with Scheme but since so much code was written in elisp, they didn’t want to throw it out. At this point someone should abstract out the Emacs definition so others could build it with Scheme or Clojure. Emacs is basically a Lisp interpreter. They wrote the parts that needed to be fast in C and the rest…
I sometimes feel that someone needs to declare "elisp bankruptcy" in the same vein as one declares inbox bankruptcy, accept that implementing all of elisp in another superior lisp is too much work, write a better emacs-alike from the ground up in a proper, performant lisp, and let the package authors do the work of porting their packages.
> let the package authors do the work of porting their packages.
Unfortunately that will never happen, and since packages are the reason anyone uses anything, no one will use the newmacs.
If there were a translation layer for backwards compatibility then that could work, but the one with more packages wins, so I don't think it could work without it.
Honest question: what are the benefits of Guile Emacs in 2020 and after? Guile speed? I'm aware Guile (especially) later versions got really good VM and general optimizations, but with recent work in gccemacs [1] and having complete gcc optimization engine under the belt, can these two be even compared? Also, gccemacs showed you get visible speedups in some use cases only. Have everything under Guile umbrella? Rememb…
Does Guix's remote build caching help avoid every Guix user having to build the full bootstrap?
I sometimes feel that someone needs to declare "elisp bankruptcy" in the same vein as one declares inbox bankruptcy, accept that implementing all of elisp in another superior lisp is too much work, write a better emacs-alike from the ground up in a proper, performant lisp, and let the package authors do the work of porting their packages.
> let the package authors do the work of porting their packages. Unfortunately that will never happen, and since packages are the reason anyone uses anything, no one will use the newmacs. If there were a translation layer for backwards compatibility then that could work, but the one with more packages wins, so I don't think it could work without it.
Neovim is getting good traction in the vim space. It turns out that developers are also annoyed by these issues on legacy platforms and are motivated to support the new system.
Guile is almost 30 years old. It’s GNU’s Scheme implementation. People wanted to replace the nonstandard Emacs Lisp with Scheme but since so much code was written in elisp, they didn’t want to throw it out. At this point someone should abstract out the Emacs definition so others could build it with Scheme or Clojure. Emacs is basically a Lisp interpreter. They wrote the parts that needed to be fast in C and the rest…
I sometimes feel that someone needs to declare "elisp bankruptcy" in the same vein as one declares inbox bankruptcy, accept that implementing all of elisp in another superior lisp is too much work, write a better emacs-alike from the ground up in a proper, performant lisp, and let the package authors do the work of porting their packages.
This has happened, and the result is VSCode.
Of course, ES6 is less powerful than Scheme, but the speed and the mindshare outweighed the homoiconicity and the macros :-\