
State of Emacs Lisp on Guile - todsacerdoti
https://emacsninja.com/posts/state-of-emacs-lisp-on-guile.html
======
dig1
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? Remember, Guile is getting trickier and
trickier to build over the years and I don't want that from scripting language
whose main idea was to embed it (presumably also ship the source alongside
your program in some cases). I'm getting impression even python source & build
is easier to ship and you can't go below that.

Also, modern Guile compilation time is abysmal. I recently ditched Guix [2]
from my system because bootstraping on fairly modern laptop would take hours,
mainly because Guile is trying to compile some helper scheme libraries needed
for guix to work and recompile everything again with 2-3 different gcc
versions (which are bootstraped too).

[1] [http://akrl.sdf.org/gccemacs.html](http://akrl.sdf.org/gccemacs.html)

[2] [https://guix.gnu.org/](https://guix.gnu.org/)

~~~
metroholografix
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 current Emacs Lisp ecosystem, and every heavy Emacs user knows it.

Guile doesn't really have much to offer, given its terrible performance, lack
of interest from developers (and some would say users), platform-compatibility
issues and strong potential for diluting a very valuable, very cohesive
ecosystem.

It is a project that is slowly languishing while Emacs Lisp is slowly but
surely getting better.

~~~
teataster
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
would not change it and it solves the domain problem just fine.

~~~
metroholografix
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 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).

~~~
progre
> These are bad Lisps because they suffer from fundamental design errors that
> go against the concept of Lisp itself.

So can you elaborate on what those design errors might be? And what exactly is
the "concept of lisp"?

~~~
metroholografix
One example:
[https://www.gnu.org/software/emacs/manual/html_node/elisp/Co...](https://www.gnu.org/software/emacs/manual/html_node/elisp/Cons-
Cells.html)

The concept of Lisp through its historic evolution refers to the set of ideas
and implementation details that allows one to read a book about Lisp written
40 years ago and apply the same concepts through a language called Lisp today
without any -major- changes.

If that's not possible or involves substantial programming logic rewriting,
the language should not be viewed as Lisp.

------
melling
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 is elisp.

45 years ago Emacs needed to be built in C. Today the entire thing could be
built with a standard Lisp.

I suppose if someone wrote an Emacs in Scheme, the projects could converge
once Guile is integrated into Emacs

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

~~~
nine_k
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 :-\

~~~
logicchains
Anecdata: I switched from VSCode to Emacs because VSCode kept freezing, have
not once regretted that decision.

~~~
nine_k
This is especially funny given ES6's allegedly superior concurrency story.

30 years in development do help avoid some pitfalls, though.

------
pcr910303
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](https://akrl.sdf.org/gccemacs.html)

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

------
davexunit
This article is pretty biased against Guile. Guile-Emacs was a very neat
experiment and the fact that it worked at all was remarkable but the prototype
didn't get traction with the Emacs devs. It should be no surprise that it has
issues because it was never completed! That's not an indictment of Guile or
Emacs (both are wonderful), there just wasn't the necessary desire to make it
happen so it fizzled out.

~~~
bjoli
Guile-emacs also used a lot of Emacs functions for elisp functionality. The
author is trying to draw conclusions from the test suite failing, but forgot
to include a large chunk of the run-time.

------
jpfr
Unfortunately, this comparison uses Guile 2.2. Guile 3 is out and has greatly
improved the performance via Wingo‘s JIT.

AFAIK the biggest point that brought Guile-Emacs to a standstill is the
internal string representation of Emacs that is different from Guile’s native
format.

~~~
bjoli
I am not sure that would help. Guile elisp is slow. I don't think there is
anything stopping it from being as fast as guile sche, except for maybe man-
hours.

------
aijony
One cool thing I'm doing with Guile Elisp is writing code that can be called
by both Guix and Emacs to deal with the packages required by my Guix and Emacs
configurations. Mind you it isn't much code, but it's really fun and I find
myself sometimes writing Elisp with the intention that I can later call it
from my Scheme projects. However, I would prefer to do it the other way
around. I would NEVER write my Emacs config in Scheme, but I'd love to write
portable libraries that could be called from any Guile supported project in
whatever language makes sense for the problem domain.

I think a lot of people miss the point of Guile Emacs. Making Emacs faster or
having access to all of Guile's features and libraries is not what the project
intends - they are just possible free perks. The purpose of Guile was to allow
any project to be extensible like Emacs with an independent module. That means
instead of the Emacs folk implementing a native compiler just for themselves,
some GNU project that uses Lua to rewrite existing Emacs Lisp libraries, or
awesome small projects like Lilypond or Gnucash to have to deal with Guile
Scheme all by themselves, all these projects can pool resources and improve
their performance and features together. Guile Emacs is not about Emacs, it's
about bringing more unity across all the islands of GNU projects.

If I had the know how / the time I would be less talk.

------
bjoli
Guile elisp is very slow. There are almost no optimization work done
whatsoever, and the dynamic state stuff is very slow still. I don't know what
the author expected, really.

I think Guile-emacs defers a lot of the core functionality to Emacs C
functions as well, which would explain the failed tests.

------
afc
> 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 that's what's at
work here, but... tests typically have timeouts for a reason (and typically
finish significantly sooner than their timeouts, for obvious reasons). :-)

~~~
dan-robertson
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.

