Guilemacs – Emacs with Guile Scheme(emacswiki.org)
emacswiki.org
Guilemacs – Emacs with Guile Scheme
https://www.emacswiki.org/emacs/GuileEmacs
24 comments
As a user of both Guile and Emacs this project has always intrigued me, but I think people arguing for speed, multitasking, or configuring Emacs in Scheme or Javascript are missing the point. Guile Emacs represents an ideal where GNU projects share a common library that all benefit from shared improvements. For example, if Guile gets native compilation, Guile Emacs, Guix, and any other Guile project gets native compilation. I would never write my Emacs config in Scheme, but I wouldn't hesitate to call a Scheme library from Emacs, or an Elisp library from a Guile project. Guile Emacs would be a huge step unifying all of these separate GNU projects from both a technical and social point of view.
I agree, though Emacs does support native compilation at the moment (it's still a work in progress though). It would have been nice if the Guile stuff go merged, but I think that ship has sailed and we should just embrace the native compiler included in Emacs.
"Guile-based Emacs is a branch of GNU Emacs that replaces Emacs’s own EmacsLisp engine with the Elisp compiler of Guile. It does not attempt to remove Elisp. One advantage is that Elisp will potentially execute faster"
Another initiative was posted here recently [1].
"GNU Emacs can currently execute Elisp code either interpreted or byte-interpreted after it has been compiled to byte-code ... exploiting libgccjit to achieve code generation using the GNU Compiler Collection (GCC) infrastructure. ... Though still a work in progress ... Native compiled Elisp shows an increase of performance ranging from 2.3x up to 42x with respect to the equivalent byte-code"
1 : https://www.reddit.com/r/emacs/comments/g9vdd0/bringing_gnu_...
Another initiative was posted here recently [1].
"GNU Emacs can currently execute Elisp code either interpreted or byte-interpreted after it has been compiled to byte-code ... exploiting libgccjit to achieve code generation using the GNU Compiler Collection (GCC) infrastructure. ... Though still a work in progress ... Native compiled Elisp shows an increase of performance ranging from 2.3x up to 42x with respect to the equivalent byte-code"
1 : https://www.reddit.com/r/emacs/comments/g9vdd0/bringing_gnu_...
[deleted]
Watching Tom Tromey's talk on the future of Emacs is a better use of your time I suspect -
https://irreal.org/blog/?p=8687
He addresses many of the "obvious" ideas many of the casuals that appear in these hn threads have.
https://irreal.org/blog/?p=8687
He addresses many of the "obvious" ideas many of the casuals that appear in these hn threads have.
Funny enough, if you rewrite all of Emacs in Elisp that would superficially seem to make Guile Emacs easier to implement. I wouldn't be surprised if by that time Guile had native compilation and an even better Elisp implementation. Ironically, it would defeat the original intention of Guile extending C programs that was inspired by Emacs, but even the Guile community is starting to lean towards Scheme-only programs with some FFI akin to Tom's ideas.
Maybe if you use Guile to rewrite the parts of Emacs that are currently written in C, and go with the dynamic translation idea currently used in Guilemacs you could achieve the same goal. Then you could rewrite Emacs in Guile at your leisure, or not, retaining elisp compatibility for historical and practical reasons alike.
You can also write your own dialect of lisp within elisp, too. I ported Lumen[1] to emacs: https://github.com/shawwn/y/blob/abcf6f4406178880390308ff0b7...
Emacs' reader can also be completely overridden by user code. I used this technique to port pg's Arc to elisp: https://repl.it/repls/UnluckySturdyCharactercode#main.el
(If you click "run" and type #\a you'll notice you get "a" rather than a syntax error.)
[1] Lumen lisp: https://github.com/sctb/lumen
(define-global cut (x &optional from upto)
(with l (dup x)
(let (j 0
i (if (or (nil? from) (< from 0)) 0 from)
n (\# x)
upto (if (or (nil? upto) (> upto n)) n upto))
(while (< i upto)
(set (at l j) (at x i))
(inc i)
(inc j))
(each (k v) x
(unless (number? k)
(set (get l k) v))))))
Emacs' reader can also be completely overridden by user code. I used this technique to port pg's Arc to elisp: https://repl.it/repls/UnluckySturdyCharactercode#main.el
(If you click "run" and type #\a you'll notice you get "a" rather than a syntax error.)
[1] Lumen lisp: https://github.com/sctb/lumen
If one is looking to improve Emacs performance, I would recommend checking out gccemacs https://akrl.sdf.org/gccemacs.html insteald, as guilemacs has stalled. gccemacs has been merged into the main emacs branch and works by compiling Elisp into dynamically loadable binaries. The performance speedups are very promising, with up to 30x speed improvements over standard byte code. I've been using it as my default emacs and it's been working very well. No crashes and Emacs is finally not slow! Now all Emacs needs is preemptive multi-threading!
I don't do much lisping or scheming these days, but my experience of Guile has be nothing but exemplary. I'm a VIM user, but I would definitely give emacs another shot if scripting it in scheme was an option (with evil-mode definitely; no way am I giving up modal editing).
> It’s best to call it “GuileEmacs” or “Guile/Emacs” or such to make it clear that it’s still GNU Emacs.
No love for Guile+Emacs?
> It’s best to call it “GuileEmacs” or “Guile/Emacs” or such to make it clear that it’s still GNU Emacs.
No love for Guile+Emacs?
I'm sure one of them will catch on just like GNU/Linux has.
This is about as correct as telling your wife that your beard will grow on her like it grew on you.
This really needs a (2016) in the title. The recent edit (not even edits) adds little to nothing and the last commit was in 2015.
With Guile 3.0 released recently, that is way faster[1] than before, it looks even more interesting. The only problem is that many distributions still didn't update yet[2].
[1] https://www.gnu.org/software/guile/news/gnu-guile-300-releas...
[2] https://repology.org/project/guile/versions
[1] https://www.gnu.org/software/guile/news/gnu-guile-300-releas...
[2] https://repology.org/project/guile/versions
I was under the impression that this effort has been stalled for 5+ years.
Is that incorrect?
Is that incorrect?
This is a stalled project, interesting but stalled.
There are changes happening elsewhere, for example the obligatory rust mashup:
https://github.com/remacs/remacs
gccemacs is probably the most interesting recent development:
https://akrl.sdf.org/gccemacs.html
There are changes happening elsewhere, for example the obligatory rust mashup:
https://github.com/remacs/remacs
gccemacs is probably the most interesting recent development:
https://akrl.sdf.org/gccemacs.html
Last commit: Tue, 12 May 2015
But to be fair Guile Elisp is doing fairly well.
But to be fair Guile Elisp is doing fairly well.
Surprisingly I found Scheme support in Emacs underwhelming (disclaimer: I'm a Windows user). The best package for Scheme in Emacs seems to be Geiser [1], but it seems pretty basic when compared with Slime [2]. Perhaps Geiser+Guile is a different story if running on Unix, but Slime on Windows just works, so that's a plus for Common Lisp :-).
1: https://www.nongnu.org/geiser/
2: https://common-lisp.net/project/slime/
1: https://www.nongnu.org/geiser/
2: https://common-lisp.net/project/slime/
My general sense is that the scheme community doesn’t have the “live system” culture the way the Common Lisp and Clojure communities do: schemes generally seem to deemphasize things like live code updates in favor of a more “batch” compiling strategy: I’ve especially noticed this when talking to people in the Racket community, but my general sense is that Racket inherited this from scheme.
I'm not sure about Schemes in general but you've described my experience of Racket precisely. It's somehow a completely different feel. For me the 'live system' Lisp spirit is fluid and always makes things modifiable and bend to the will of the programmer. The 'batch' sensibility thwarts this. It shows up particularly in module systems that force you to jump through hoops that aren't worth it and that compound into difficulty upon difficulty. In this respect the Common Lisp package system has always struck me as a miracle of design: it allows disparate systems to compose, while allowing the programmer full access to whatever they want to do. You just sometimes need to type an extra colon—a small price to pay.
My impression of Scheme in general as well. Scheme REPL top-levels typically come with some caveats which is an indicator of live system programming being a second class feature.
I'm quite an amateur schemer and have never used Racket, but Christopher Webber's talk [1] gives me the opposite impression and that Racket diverged from the "live system" culture. In my experience Guile is usually pretty good when it comes to updating things on the fly through the REPL, but there are some gotchas.
[1] https://archive.fosdem.org/2019/schedule/event/guileracket/
[1] https://archive.fosdem.org/2019/schedule/event/guileracket/
Geiser+Guile does work quite fine under Linux for me. Speaking of Scheme and Slime, I have heard of Swank which is for using MIT, Ikarus, Larceny, and Kawa Schemes in Slime.
A couple points to note: This works by dynamically translating elisp to Guile Scheme, which is crucial to ensuring that decades worth of elisp will work without change. However, in Guilemacs, one can use Scheme as well as el as extension languages.
Also while it works, it's quite slow at this point in time and, unlike Emacs which rarely if ever crashes, Guilemacs can and will crash.
Also while it works, it's quite slow at this point in time and, unlike Emacs which rarely if ever crashes, Guilemacs can and will crash.