Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of Emacs Lisp on Guile

emacsninja.com

Post reply on HN
Print view View original

51–60 of 66 posts

Re: State of Emacs Lisp on Guile

#51

Post by heintje_ghulam »

metroholografix wrote: post #39
pmoriarty wrote: post #36

Earlier quoted context omitted.

"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…

I think it's safe to say at this point -more than 10 years later- that Andy Wingo was very optimistic. 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, witho…

It might be the case that being able to use Emacs Lisp outside of the Emacs editor in a (potentially) more robust environment designed for general purpose programming could potentially give Emacs Lisp more legitimacy as a programming language in its own right (not just "a scripting language for an editor").

However, it seems that some people have another goal in mind with the Guile-based Elisp: actually replacing Emacs Lisp, or phasing it out, or whatever. I think that is a terrible idea. I also think their goal of mixing languages inside of Emacs would have the negative consequences you describe.

Re: State of Emacs Lisp on Guile

#52

Post by pmoriarty »

metroholografix wrote: post #49
pmoriarty wrote: post #48

Earlier quoted context omitted.

"Plenty of folks have implemented Emacs in various languages (using the same "abstracted out" definition) and guess what, all of them went nowhere." If they were: 1 - Lispy 2 - Faster 3 - Fully compatible with existing eLisp packages. I think people would switch. Guile Emacs is all of those except (at this point) faster.. when I tried it, it was unfortunately way slower. If the speed could be improved a lot and the r…

> Guile Emacs is all of those except (at this point) faster. Guile Emacs is not at all compatible with Emacs Lisp, it only implements a tiny subset of Emacs Lisp. It's right there in OP's article. So the only thing it has going for it is being .. Lispy. Not enough.

In my own testing from Nov 2017, I got GUI Emacs to run.. it was slow, but it ran.

Vanilla GUI Emacs runs a non-trivial amount of eLisp code, so at least then with the version of Emacs I used (24.4.50) the compatibility situation could not have been dire than what the OP reported.

Also, you have to bear in mind that Guile Emacs was the work of one single (very talented) person over a single summer.

If there was actually a team of people working on it, I expect a lot more progress towards compatibility could be made.

Here is a list of outstanding items that still need to be worked on Guile Emacs:

https://www.emacswiki.org/emacs/GuileEmacsTodo

Re: State of Emacs Lisp on Guile

#53

Post by heintje_ghulam »

pmoriarty wrote: post #45
metroholografix wrote: post #44

Earlier quoted context omitted.

I don't agree with your view either. Going through C is not a counterargument, since it's doesn't compete with interactive development in Emacs Lisp. The technical drawbacks are many and for that very reason you see no fragmentation in the ecosystem today. Being able to write a Lua or JavaScript function on the fly, inside Emacs, and having Guile execute it would make these languages direct competitors to Emacs Lisp.…

I would firmly oppose switching the entirety of the Emacs ecosystem to JS, Lua, Rust or any other non-Lispy language, but that's not what we're talking about here. If an occasionaly JS or Lua package becomes available through Guile, what's the harm? Anyway, I don't see this as the primary benefit of Guile Emacs.. the rest benefits that Andy Wingo mentions are much more interesting and valuable to me, not JS/Lua compa…

The problem with your point of view is that if it came to pass, then anyone who wanted to work on Emacs packages would have to learn multiple programming languages when before they only needed one, Elisp.

Having packages in multiple languages hurts the ability of people to help contribute to each others' work (especially if they don't have time or space to learn multiple languages).

Re: State of Emacs Lisp on Guile

#54

Post by ssivark »

nine_k wrote: post #20
na85 wrote: post #12

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.

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

Speed and mindshare don’t make up for a lack of flexibility and power. No one’s gonna be running a window manager based on VS Code, and that should tell you something (see EXWM)

Re: State of Emacs Lisp on Guile

#55

Post by bjoli »

metroholografix wrote: post #49
pmoriarty wrote: post #48

Earlier quoted context omitted.

"Plenty of folks have implemented Emacs in various languages (using the same "abstracted out" definition) and guess what, all of them went nowhere." If they were: 1 - Lispy 2 - Faster 3 - Fully compatible with existing eLisp packages. I think people would switch. Guile Emacs is all of those except (at this point) faster.. when I tried it, it was unfortunately way slower. If the speed could be improved a lot and the r…

> Guile Emacs is all of those except (at this point) faster. Guile Emacs is not at all compatible with Emacs Lisp, it only implements a tiny subset of Emacs Lisp. It's right there in OP's article. So the only thing it has going for it is being .. Lispy. Not enough.

That is because op didn't run it in Emacs. Guile-emacs uses the same Emacs c functions that Emacs elisp does, and running the Emacs tests against guiles elisp-without Emacs is like taking away a huge part of the standard functionality and expecting things to run.

The points it makes about speed are not wrong, but that the author fails to understand even the most basic relations between Guile-emacs and guile-elisp makes it hard for me to take it seriously.

Re: State of Emacs Lisp on Guile

#56

Post by bjoli »

davexunit wrote: post #10

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.

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.

Re: State of Emacs Lisp on Guile

#57

Post by opan »

eeh wrote: post #18
dig1 wrote: post #9

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

It's not uncommon to have to build things because you've updated earlier than some others. I remember waiting hours for Rust, webkitgtk, or cataclysm-dda to build on multiple occasions. Sometimes just waiting another day would mean a substitute was available. You could also update your current profile with the exclusion of a few packages, such as the ones that have no substitutes. This is nice, but because it updates your current profile, then you can't remove something you were planning to remove via your package declarations, you're introducing your state then. A temporary issue that gets fixed when you can next apply your package manifest, though.

Re: State of Emacs Lisp on Guile

#58

Post by erik_seaberg »

heintje_ghulam wrote: post #53
pmoriarty wrote: post #45

Earlier quoted context omitted.

I would firmly oppose switching the entirety of the Emacs ecosystem to JS, Lua, Rust or any other non-Lispy language, but that's not what we're talking about here. If an occasionaly JS or Lua package becomes available through Guile, what's the harm? Anyway, I don't see this as the primary benefit of Guile Emacs.. the rest benefits that Andy Wingo mentions are much more interesting and valuable to me, not JS/Lua compa…

The problem with your point of view is that if it came to pass, then anyone who wanted to work on Emacs packages would have to learn multiple programming languages when before they only needed one, Elisp. Having packages in multiple languages hurts the ability of people to help contribute to each others' work (especially if they don't have time or space to learn multiple languages).

This smacks of the https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma. If we're afraid that people will want to write packages in Blub for some reason, and we refuse to accommodate Blub at all, we're just driving everyone to some other editor that embraces it.

Re: State of Emacs Lisp on Guile

#59

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

Re: State of Emacs Lisp on Guile

#60

Post by eeh »

opan wrote: post #57
eeh wrote: post #18

Earlier quoted context omitted.

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

It's not uncommon to have to build things because you've updated earlier than some others. I remember waiting hours for Rust, webkitgtk, or cataclysm-dda to build on multiple occasions. Sometimes just waiting another day would mean a substitute was available. You could also update your current profile with the exclusion of a few packages, such as the ones that have no substitutes. This is nice, but because it updates…

I can understand why following the master branch can result in massive rebuilds.

Does Guix offer a branch that contains code that has been built by the CI builders? In which case, when a user grabs a package they'll be able to grab the compiled version rather than have to compile it themselves.

Post reply on HN