31–40 of 66 posts
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
Earlier quoted context omitted.
The are no benefits. In fact, what few folks consider benefits -be able to extend Emacs with JavaScript or Scheme- I think are major issues that have the potential to destroy Emacs. Emacs Lisp fits the problem domain like a glove. Someone in this thread called it 'the worst Lisp' but that's a mischaracterization. It's actually a good, practical, Lisp and far from the worst. In short, there is enormous value in the cu…
I called it "probably" the worst lisp. I enjoy very much working with elisp, and almost 100% agree with your characterization of it. But it is a fairly clunky language with all it's let, letstar, letdash, letstardash... You know what I mean. I am no elisp history expert, but I believe that is due to it's age and how easy it is to extend. And just to reiterate, I have never felt limited by it, I really like it, I woul…
On the other hand languages like TXR Lisp and Emacs Lisp have made certain compromises in order to better fit their problem domains, but are fully aligned with the core ideas of Lisp as defined through its historical evolution.
I also don't see let, letstar, etc as clunky but I've also been using them for more than a decade (and am firmly in the Lisp Machine Lisp -> Common Lisp camp).
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? https://guix.gnu.org/manual/en/html_node/Substitutes.html
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
Earlier quoted context omitted.
I called it "probably" the worst lisp. I enjoy very much working with elisp, and almost 100% agree with your characterization of it. But it is a fairly clunky language with all it's let, letstar, letdash, letstardash... You know what I mean. I am no elisp history expert, but I believe that is due to it's age and how easy it is to extend. And just to reiterate, I have never felt limited by it, I really like it, I woul…
There are Lisps out there that are actually bad. For example, I find every Clojure-inspired neoLisp to be bad. Or something like newLISP. These are bad Lisps because they suffer from fundamental design errors that go against the concept of Lisp itself. On the other hand languages like TXR Lisp and Emacs Lisp have made certain compromises in order to better fit their problem domains, but are fully aligned with the cor…
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…
Here is what Andy Wingo had to say on the subject[1]:
Guile can implement Emacs Lisp better than Emacs can.
We can compile Emacs Lisp to Guile's VM, and make C shims to present a suitably compatible C interface to the rest of Emacs' C primitives.
No one will notice! Except that after a switch, Emacs would be faster, more powerful, and have the ability to access all of Guile's facilities -- the Scheme language, other languages implemented for Guile (Javascript, Lua, ...), a proper ffi, dynamically loadable libraries, a module system, the numeric tower (rationals, bignums, etc), Guile's existing libraries, delimited continuations (!), fast bytevector access, native threads, etc.
On a language level, I am convinced that not only can Guile implement Emacs Lisp, but it can provide a coherent story for tight interaction between e.g. minor modes in Javascript and Scheme and Elisp, etc. More details will come later, though feel free to bring up specific points.
There have been some suggestions on the list that "Guile people want to rewrite Emacs in Scheme". Though Scheme does have some facilities to offer, personally I do not believe in rewriting software. I've failed enough times, thank-you-very-much -- and if we could retrofit a compiler into Guile in two years via correctness-preserving transformations, surely we can replace the implementation of Elisp without causing problems.
My goal is to make it the obvious decision for the Emacs maintainers to say, "yes, let's switch to Guile's implementation of elisp, because it will make Emacs better and have no drawbacks". We're not there yet -- and that's why I wanted to put off this mail -- but we'll get there.
[1] - https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00...
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…
The are no benefits. In fact, what few folks consider benefits -be able to extend Emacs with JavaScript or Scheme- I think are major issues that have the potential to destroy Emacs. Emacs Lisp fits the problem domain like a glove. Someone in this thread called it 'the worst Lisp' but that's a mischaracterization. It's actually a good, practical, Lisp and far from the worst. In short, there is enormous value in the cu…
It is wrong to say that Guile has terrible performance. Guile Scheme is more performant than the standard implementations of elisp, python, ruby, and other so-called scripting languages. Each major release of Guile has had significant performance improvements, most recently a JIT compiler. It is true that the elisp implementation on Guile is slow, but that's a reflection of the project being a prototype and not production-ready. It could be fast if there was interest in developing it, but there isn't so it's just another interesting but dead project.
Earlier quoted context omitted.
I called it "probably" the worst lisp. I enjoy very much working with elisp, and almost 100% agree with your characterization of it. But it is a fairly clunky language with all it's let, letstar, letdash, letstardash... You know what I mean. I am no elisp history expert, but I believe that is due to it's age and how easy it is to extend. And just to reiterate, I have never felt limited by it, I really like it, I woul…
There are Lisps out there that are actually bad. For example, I find every Clojure-inspired neoLisp to be bad. Or something like newLISP. These are bad Lisps because they suffer from fundamental design errors that go against the concept of Lisp itself. On the other hand languages like TXR Lisp and Emacs Lisp have made certain compromises in order to better fit their problem domains, but are fully aligned with the cor…
So can you elaborate on what those design errors might be? And what exactly is the "concept of lisp"?
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…
"what are the benefits of Guile Emacs in 2020 and after?" Here is what Andy Wingo had to say on the subject[1]: Guile can implement Emacs Lisp better than Emacs can. We can compile Emacs Lisp to Guile's VM, and make C shims to present a suitably compatible C interface to the rest of Emacs' C primitives. No one will notice! Except that after a switch, Emacs would be faster, more powerful, and have the ability to acces…
Absolutely nothing of what he described in that email materialized. And it's no wonder it didn't, since a lot of it is simply wishful thinking. In addition, he didn't address the fact that there are political and not technical reasons behind the absence of certain features (e.g. FFI). They could be done today, without Guile, assuming a consensus on the political front existed.
On the other hand, Emacs Lisp has gotten a lot better and not only knocked out some of the features mentioned by Andy (dynamic modules, native threads) but is also making progress towards new directions (GCCEmacs).
And as I described in my other comment, I completely disagree with his premise that having Emacs be extended in JavaScript, Lua etc would be a plus. The last thing you do with a cohesive ecosystem like Emacs Lisp's is to introduce needless fragmentation that takes away its core strengths.
Earlier quoted context omitted.
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.
Honest question. What's wrong with elisp? I have never been limited by it. Granted, it's probably the worst lisp. But it works just fine for it's intended use. It could be argued that is one of the most used lisps. As for porting packages, some are old and will never get ported and packages are the spice of emacs.