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

41–50 of 66 posts

Re: State of Emacs Lisp on Guile

#41

Post by sterlind »

davexunit wrote: post #33
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

Yes, I'm not sure why they are doing a full bootstrap. A full bootstrap takes ages for any distro and Guix goes even further than other distros by constantly reducing the size of their binary seed as they work towards a human auditable seed which comes at the expense of increased bootstrapping time.

At least on nix, I often cache miss the Hydra builds because I'm running unstable. Maybe they set something that's making them bootstrap?

Re: State of Emacs Lisp on Guile

#42

Post by pmoriarty »

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…

"I completely disagree with his premise that having Emacs be extended in JavaScript, Lua etc would be a plus"

I also disagree, but that boat sailed long ago... For years now Emacs has allowed dynamic module loading, which lets Emacs be extended by C or anything that compiles down to C (which is pretty much any language). So it can already be done.

What Guile will offer is in some cases skipping the module compilation step, and allow more direct access to languages which can be used through the Guile interpreter.

Furthermore, whether you or I like the idea of extending Emacs through Javascript or Lua, there are plenty of other Emacs users who do, and I say let them at it!

Emacs needs more new users, and if some can be attracted through compatibility with their favorite language, I welcome them.

I'd personally like to keep Emacs pure and Lispy, but that's already not true and it's very unlikely we're going to go back.

That's not to mention that significant parts of core Emacs has been written in C for decades now. It'd be much nicer if some of that C code could be rewritten in Scheme.

Re: State of Emacs Lisp on Guile

#43

Post by metroholografix »

progre wrote: post #38
metroholografix wrote: post #32

Earlier quoted context omitted.

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…

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

One example: https://www.gnu.org/software/emacs/manual/html_node/elisp/Co...

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.

Re: State of Emacs Lisp on Guile

#44

Post by metroholografix »

pmoriarty wrote: post #42
metroholografix wrote: post #39

Earlier quoted context omitted.

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…

"I completely disagree with his premise that having Emacs be extended in JavaScript, Lua etc would be a plus" I also disagree, but that boat sailed long ago... For years now Emacs has allowed dynamic module loading, which lets Emacs be extended by C or anything that compiles down to C (which is pretty much any language). So it can already be done. What Guile will offer is in some cases skipping the module compilation…

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. You would expect to see newcomers take the easy way out and never bother with Emacs Lisp. Fragmentation. Dilution. That is the core issue.

You seem to think that these sort of sacrifices should be made in the interest of popularity. I don't agree at all. Emacs has no reason to make populist compromises. It has certain qualities that have stood the test of time and have kept it extremely powerful. To go on the populist road would ensure that Emacs becomes just like everything else out there. A mediocrity.

Re: State of Emacs Lisp on Guile

#45

Post by pmoriarty »

metroholografix wrote: post #44
pmoriarty wrote: post #42

Earlier quoted context omitted.

"I completely disagree with his premise that having Emacs be extended in JavaScript, Lua etc would be a plus" I also disagree, but that boat sailed long ago... For years now Emacs has allowed dynamic module loading, which lets Emacs be extended by C or anything that compiles down to C (which is pretty much any language). So it can already be done. What Guile will offer is in some cases skipping the module compilation…

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

I'd also much prefer to write my own Emacs code in Scheme than eLisp (though, again, Guile Emacs does not entail replacing eLisp packages with Scheme -- you can still use eLisp if you want, and existing eLisp packages will still work).

Re: State of Emacs Lisp on Guile

#46

Post by jjdredd »

pcr910303 wrote: post #6

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

Integrating a compiler into a text editor to speed it up is a bit of an overkill imo. What if a lisp source changes and needs to be recompiled? What if several lisp files change? Does it mean that it also needs a sort of a build system? This brings the joke about an "operating system that lacks a decent editor" closer to reality (or reality closer to the joke).

Re: State of Emacs Lisp on Guile

#47

Post by metroholografix »

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…

I don't think you'll be able to control occasional or not. This is a Pandora's box [1] situation. Either you open it or you don't. And having alternative languages as direct competitors to Emacs Lisp, available for interactive development, would certainly be blowing the box apart.

I wouldn't mind Scheme as an alternative, the only alternative, except I don't think I'd use it myself since I would still see Emacs Lisp as domain-superior.

Agreed on the rest, except as I said, none of that materialized from the Guile camp whilst we had plenty of that goodness emerge in core Emacs.

[1] https://en.wikipedia.org/wiki/Pandora%27s_box

Re: State of Emacs Lisp on Guile

#48

Post by pmoriarty »

metroholografix wrote: post #29
melling wrote: post #5

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…

You are assuming many things that are simply not true. There is no goal or will to integrate Guile in Emacs. It was a failed experiment taken up by volunteers outside of the core Emacs development team. Most of the value in the Emacs ecosystem lies in Emacs Lisp and not in an "abstracted out" Emacs definition. Plenty of folks have implemented Emacs in various languages (using the same "abstracted out" definition) and…

"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 remaining bugs ironed out, it would be a very strong contender.

Re: State of Emacs Lisp on Guile

#49

Post by metroholografix »

pmoriarty wrote: post #48
metroholografix wrote: post #29

Earlier quoted context omitted.

You are assuming many things that are simply not true. There is no goal or will to integrate Guile in Emacs. It was a failed experiment taken up by volunteers outside of the core Emacs development team. Most of the value in the Emacs ecosystem lies in Emacs Lisp and not in an "abstracted out" Emacs definition. Plenty of folks have implemented Emacs in various languages (using the same "abstracted out" definition) and…

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

Re: State of Emacs Lisp on Guile

#50

Post by throwaway894345 »

tines wrote: post #23
throwaway894345 wrote: post #19

Earlier quoted context omitted.

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.

I'm not familiar with the vim world. How different is the neovim API? Do the developers maintain two versions of their plugins?

I'm not that familiar with the details. My understanding is that neovim at least mostly supports the vim language, but also offers other APIs (not clear about whether these APIs are extensions of the VIM language or altogether different) that allow developers to work around common VIM issues. My crude impression is that developers actively prefer to interface with the new APIs, and many packages aren't even backwards compatible with VIM.
Post reply on HN