diff options
Diffstat (limited to '')
-rw-r--r-- | 2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--main.vtt | 601 |
1 files changed, 601 insertions, 0 deletions
diff --git a/2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--main.vtt b/2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--main.vtt new file mode 100644 index 00000000..b4e7cdc8 --- /dev/null +++ b/2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--main.vtt @@ -0,0 +1,601 @@ +WEBVTT captioned by sachac and robin + +00:00:00.000 --> 00:00:03.839 +Hello everyone. I'm Robin Templeton, and I'm going to talk + +00:00:03.840 --> 00:00:07.919 +about Emacs Beguiled and recent progress on the Guile-Emacs + +00:00:07.920 --> 00:00:13.919 +project. + +00:00:13.920 --> 00:00:16.839 +First of all, if you're not familiar with Guile, it's an + +00:00:16.840 --> 00:00:20.239 +implementation of the Scheme programming language, which + +00:00:20.240 --> 00:00:24.799 +is a dialect of Lisp, and in the same family as Emacs Lisp, and + +00:00:24.800 --> 00:00:28.759 +Guile is GNU's official extension language. The goal of + +00:00:28.760 --> 00:00:32.679 +the Guile-Emacs project is to use Guile as the basis for + +00:00:32.680 --> 00:00:37.599 +Emacs's Lisp support. It has two main components: a new + +00:00:37.600 --> 00:00:41.919 +Emacs Lisp compiler built on top of Guile, and a variant of + +00:00:41.920 --> 00:00:45.199 +Emacs in which the built-in Lisp implementation is + +00:00:45.200 --> 00:00:50.239 +entirely replaced with Guile Elisp. We expect the + +00:00:50.240 --> 00:00:53.439 +combination of these two projects to have several + +00:00:53.440 --> 00:00:57.999 +benefits. One is improved performance. Another is + +00:00:58.000 --> 00:01:03.839 +increased expressiveness for Elisp and making it easier to + +00:01:03.840 --> 00:01:07.839 +extend and experiment with the language. Finally, it + +00:01:07.840 --> 00:01:13.079 +will reduce Emacs's reliance on C for two reasons. Guile will + +00:01:13.080 --> 00:01:16.959 +be responsible for the language implementation, so Emacs + +00:01:16.960 --> 00:01:21.559 +will no longer have to include a Lisp interpreter. It + +00:01:21.560 --> 00:01:25.759 +will also become possible to implement much more of Emacs in + +00:01:25.760 --> 00:01:30.279 +Lisp than is currently feasible. Of course, this raises + +00:01:30.280 --> 00:01:34.119 +the question of why Guile is suitable for this project. And + +00:01:34.120 --> 00:01:38.079 +we chose Guile for a few reasons. Guile is primarily a Scheme + +00:01:38.080 --> 00:01:41.119 +implementation, but it also has built-in support for + +00:01:41.120 --> 00:01:44.399 +multiple languages using its compiler tower. To add + +00:01:44.400 --> 00:01:50.079 +support for a new language to Guile, you only have to write a + +00:01:50.080 --> 00:01:53.399 +compiler from the source language to Tree-IL, which is + +00:01:53.400 --> 00:01:57.439 +essentially a low-level, minimal representation of + +00:01:57.440 --> 00:02:02.479 +Scheme. All of Guile's compiler optimizations occur at the + +00:02:02.480 --> 00:02:07.599 +Tree-IL layer or lower, so you don't need to worry about the + +00:02:07.600 --> 00:02:10.159 +lower-level details of the compiler when initially + +00:02:10.160 --> 00:02:14.639 +implementing your language. Guile also has some Lisp + +00:02:14.640 --> 00:02:18.879 +features that are very rare in Scheme implementations. For + +00:02:18.880 --> 00:02:22.599 +example, it has a nil value that counts as both false and an + +00:02:22.600 --> 00:02:27.759 +empty list, just like in Elisp, and it also has a version of + +00:02:27.760 --> 00:02:32.319 +the Common Lisp Object System and its metaobject protocol, + +00:02:32.320 --> 00:02:37.239 +which is called GOOPS. + +00:02:37.240 --> 00:02:42.199 +The idea of Guile-Emacs has a pretty long history, going back + +00:02:42.200 --> 00:02:45.319 +at least three decades. There have been about half a dozen + +00:02:45.320 --> 00:02:48.519 +previous implementation attempts. But the current + +00:02:48.520 --> 00:02:51.519 +iteration began with a series of six Summer of Code + +00:02:51.520 --> 00:02:56.279 +internships: Daniel Kraft's in 2009, and then my + +00:02:56.280 --> 00:03:02.519 +internships from 2010 to 2014. My basic implementation + +00:03:02.520 --> 00:03:06.319 +strategy was pretty straightforward. I implemented a core + +00:03:06.320 --> 00:03:09.679 +subset of Elisp, which was enough to run some batch mode + +00:03:09.680 --> 00:03:15.399 +programs outside of Emacs. In Emacs, I modified the garbage + +00:03:15.400 --> 00:03:19.679 +collector and the data structures for Lisp objects to use + +00:03:19.680 --> 00:03:24.679 +their libguile equivalents. I replaced Emacs' Lisp + +00:03:24.680 --> 00:03:32.199 +evaluator with the one provided by Guile Elisp. + +00:03:32.200 --> 00:03:35.919 +After a little over a year of work, at the end of the 2014 + +00:03:35.920 --> 00:03:41.079 +internship, I ended up with a fully functional prototype of + +00:03:41.080 --> 00:03:46.039 +Guile-Emacs. It used Guile Elisp alone as its Lisp + +00:03:46.040 --> 00:03:53.319 +implementation and was completely compatible with Emacs + +00:03:53.320 --> 00:03:57.559 +functionality and with external extensions. One caveat + +00:03:57.560 --> 00:04:01.399 +was that performance was pretty bad, because I was focused + +00:04:01.400 --> 00:04:05.639 +on correctness, as well as ease of integration with the + +00:04:05.640 --> 00:04:10.559 +Emacs C code. But it was nonetheless a major milestone for + +00:04:10.560 --> 00:04:15.759 +the project. Let's take just a moment to look at + +00:04:15.760 --> 00:04:19.599 +Guile-Elisp. + +00:04:19.600 --> 00:04:23.879 +For starters, we have access to Guile modules. If we call + +00:04:23.880 --> 00:04:26.959 +Guile's <i>version</i> function, we can see that we're running + +00:04:26.960 --> 00:04:33.879 +under Guile 3.0. We have access to some of the numeric tower via + +00:04:33.880 --> 00:04:41.279 +the arithmetic functions. We also have multiple values. We + +00:04:41.280 --> 00:04:45.599 +have to be careful to use Guile's <i>values</i> procedure here, not + +00:04:45.600 --> 00:04:48.839 +the CL library's, but you can see that this works properly + +00:04:48.840 --> 00:04:52.879 +rather than being an emulation. Finally, we have tail + +00:04:52.880 --> 00:04:57.999 +call elimination. Naturally, we're going to use factorial + +00:04:58.000 --> 00:05:07.159 +to demonstrate it. If <i>n</i> is zero, return the answer, else + +00:05:07.160 --> 00:05:14.199 +recurse with <i>n</i> less one and <i>n</i> times <i>a</i>. + +00:05:14.200 --> 00:05:17.119 +Of course, this definition works correctly, but it gets + +00:05:17.120 --> 00:05:21.759 +more interesting if we communicate the answer with an + +00:05:21.760 --> 00:05:27.759 +error, + +00:05:27.760 --> 00:05:32.359 +in order to look at a backtrace. You can see here that there are no + +00:05:32.360 --> 00:05:37.839 +calls to <i>fact</i> visible in between the request to evaluate and + +00:05:37.840 --> 00:05:42.199 +the error communicating the answer. That's because + +00:05:42.200 --> 00:05:53.319 +this tail call has been optimized into effectively a goto. + +00:05:53.320 --> 00:05:55.759 +This is essential for any kind of serious functional + +00:05:55.760 --> 00:06:00.279 +programming. + +00:06:00.280 --> 00:06:05.359 +That's a peek at Guile-Elisp. In 2015, I left university + +00:06:05.360 --> 00:06:09.479 +to go work on web technologies, and the project was dormant + +00:06:09.480 --> 00:06:14.679 +for a very long time. But that's been changing recently. + +00:06:14.680 --> 00:06:17.039 +During the last few months, I've been working with Larry + +00:06:17.040 --> 00:06:23.399 +Valkama to rebase Guile-Emacs onto the development branch + +00:06:23.400 --> 00:06:28.319 +of upstream Emacs, including the past decade's worth of + +00:06:28.320 --> 00:06:33.399 +upstream development. What we've ended up with is a series + +00:06:33.400 --> 00:06:38.839 +of rebases onto different versions of Emacs. The older ones + +00:06:38.840 --> 00:06:44.239 +tend to work pretty well. The newer ones have increasingly + +00:06:44.240 --> 00:06:49.799 +bad problems where they haven't been properly adjusted for + +00:06:49.800 --> 00:06:55.599 +changes in the Emacs implementation. But we do have by now a + +00:06:55.600 --> 00:06:58.919 +version of Emacs 30 which boots correctly and can be used for + +00:06:58.920 --> 00:07:04.959 +interactive debugging, as well as the ability to bisect the + +00:07:04.960 --> 00:07:08.919 +revisions of Emacs and find out where regressions were + +00:07:08.920 --> 00:07:13.199 +introduced. Our immediate goal is of course to complete + +00:07:13.200 --> 00:07:19.719 +the rebase. At the same time, we want to improve Guile Elisp's + +00:07:19.720 --> 00:07:22.799 +performance to at least be competitive with ordinary Emacs + +00:07:22.800 --> 00:07:29.279 +Lisp. Just to characterize the performance situation, + +00:07:29.280 --> 00:07:34.479 +Guile Elisp is usually about half as fast as ordinary Elisp, + +00:07:34.480 --> 00:07:37.839 +while Guile Scheme is quite often an order of magnitude + +00:07:37.840 --> 00:07:43.319 +faster than ordinary Elisp, and that's based on micro + +00:07:43.320 --> 00:07:47.799 +benchmarks like the Gabriel benchmarks. But there's + +00:07:47.800 --> 00:07:52.319 +clearly a lot of room to improve our compiler's output. + +00:07:52.320 --> 00:07:57.759 +If you want to mark your calendars, we're expecting to have a + +00:07:57.760 --> 00:08:04.199 +usable version of Guile-Emacs 30 out sometime next spring. We're + +00:08:04.200 --> 00:08:06.799 +also going to put some effort into either extracting old + +00:08:06.800 --> 00:08:13.599 +work or doing new work that could be contributed upstream. + +00:08:13.600 --> 00:08:17.559 +On the Guile side, we'll probably start out with optimizing + +00:08:17.560 --> 00:08:22.839 +the dynamic binding facilities, which are used very seldom + +00:08:22.840 --> 00:08:27.199 +in Scheme, but are used all the time in traditional Lisp + +00:08:27.200 --> 00:08:31.399 +dialects. On the Emacs side, we'll be working initially on + +00:08:31.400 --> 00:08:35.919 +abstracting away the details of the Lisp implementation + +00:08:35.920 --> 00:08:39.999 +where they're not relevant. And that will clean up the Emacs + +00:08:40.000 --> 00:08:44.279 +code base a bit. It'll make it easier to integrate Emacs and + +00:08:44.280 --> 00:08:49.919 +Guile Elisp. It will probably be helpful for anyone who + +00:08:49.920 --> 00:08:51.559 +is working on ordinary Elisp on their own. + +00:08:51.560 --> 00:08:57.199 +We're also going to be adding new features to Emacs Lisp. + +00:08:57.200 --> 00:09:01.639 +We've seen a few of them already. The numeric tower, tail + +00:09:01.640 --> 00:09:05.919 +call optimization, Common Lisp compatibility. We're also + +00:09:05.920 --> 00:09:10.359 +going to provide access to Fibers, which is a Guile library + +00:09:10.360 --> 00:09:14.639 +based on ideas from Concurrent ML that provides much more + +00:09:14.640 --> 00:09:17.679 +powerful facilities for concurrent and parallel + +00:09:17.680 --> 00:09:20.679 +programming than what Emacs currently offers. + +00:09:20.680 --> 00:09:33.759 +This plan meets Guile-Emacs' basic goals, and it's work + +00:09:33.760 --> 00:09:36.879 +that we could maybe get integrated upstream in a reasonable + +00:09:36.880 --> 00:09:41.799 +amount of time. But it's also worth considering what more we + +00:09:41.800 --> 00:09:47.239 +can do, and what effect Guile-Emacs might have on Emacs if it + +00:09:47.240 --> 00:09:49.079 +becomes simply Emacs. + +00:09:49.080 --> 00:09:54.599 +For context, the amount of C code in Emacs has increased by + +00:09:54.600 --> 00:09:58.559 +around 50% in the last decade, and now it constitutes around + +00:09:58.560 --> 00:10:06.399 +a quarter of the code base. C can be a bit of a barrier to + +00:10:06.400 --> 00:10:13.279 +customizing and extending Emacs. For example, there are + +00:10:13.280 --> 00:10:20.439 +about 1500 C subroutines. Around 500 are used in C code, as + +00:10:20.440 --> 00:10:26.519 +well as available to Lisp code, and being written in C means + +00:10:26.520 --> 00:10:31.519 +that they can't be practically redefined. The use of C can + +00:10:31.520 --> 00:10:35.839 +become a barrier to extending Emacs or customizing its + +00:10:35.840 --> 00:10:40.479 +behavior. We might consider writing as much of Emacs as + +00:10:40.480 --> 00:10:46.039 +possible in Lisp. One way to speed up this process would + +00:10:46.040 --> 00:10:52.199 +be to provide a Common Lisp implementation for Guile. Note + +00:10:52.200 --> 00:10:56.199 +that between Guile Elisp and Guile Scheme, we have all of + +00:10:56.200 --> 00:10:58.839 +the essential ingredients for a Common Lisp environment. + +00:10:58.840 --> 00:11:03.279 +We can also share code with other Common Lisp + +00:11:03.280 --> 00:11:12.479 +implementations such as SBCL and SICL. Overall, the + +00:11:12.480 --> 00:11:15.959 +duration of the project will be better measured in months + +00:11:15.960 --> 00:11:19.479 +rather than years, despite Common Lisp's reputation for + +00:11:19.480 --> 00:11:23.959 +being a large language. This could have multiple uses, of + +00:11:23.960 --> 00:11:29.199 +course. It could be a model for future improvements to + +00:11:29.200 --> 00:11:38.399 +Elisp, because Elisp and CL can interact directly without + +00:11:38.400 --> 00:11:41.319 +problems. And it would be very easy for Elisp to borrow + +00:11:41.320 --> 00:11:45.479 +language features from Common Lisp. But for the purpose of a + +00:11:45.480 --> 00:11:49.559 +C to Lisp transition, it would also provide us with instant + +00:11:49.560 --> 00:11:52.599 +access to a huge number of high-quality libraries for + +00:11:52.600 --> 00:11:58.159 +things that Guile is not necessarily equipped to deal with, + +00:11:58.160 --> 00:12:03.879 +such as access to low-level Windows APIs, as well as lots of + +00:12:03.880 --> 00:12:08.799 +other libraries, such as interfaces to GUI toolkits for a + +00:12:08.800 --> 00:12:12.079 +variety of operating systems. + +00:12:12.080 --> 00:12:21.799 +At a certain point, this has technical advantages. If + +00:12:21.800 --> 00:12:26.119 +most of Emacs is written in Lisp, then we could consider + +00:12:26.120 --> 00:12:30.759 +using Guile Hoot to compile Emacs to WebAssembly, making it + +00:12:30.760 --> 00:12:35.159 +available perhaps in web browsers or on systems with the + +00:12:35.160 --> 00:12:40.679 +WebAssembly System Interface. But it would also be a great + +00:12:40.680 --> 00:12:44.759 +victory for practical software freedom. That's the idea + +00:12:44.760 --> 00:12:48.359 +that Freedom One, the freedom to study and modify programs, + +00:12:48.360 --> 00:12:52.039 +should not just be legally and technically possible, but + +00:12:52.040 --> 00:12:54.719 +should be actively encouraged by our computing + +00:12:54.720 --> 00:12:58.959 +environments. Emacs is really one of the archetypal + +00:12:58.960 --> 00:13:02.519 +examples of this, but we can and should go further. + +00:13:02.520 --> 00:13:10.919 +When Emacs is implemented primarily in Lisp, the entirety + +00:13:10.920 --> 00:13:14.599 +of the system will be transparent to examination and open to + +00:13:14.600 --> 00:13:20.359 +modification. Every part of Emacs will be instantaneously + +00:13:20.360 --> 00:13:23.319 +inspectable, redefinable, and debuggable. + +00:13:23.320 --> 00:13:30.559 +This will be a fundamental change in what is possible to + +00:13:30.560 --> 00:13:36.159 +do with Emacs extensions. For example, one experiment I'd + +00:13:36.160 --> 00:13:40.319 +be interested in is using the Common Lisp Interface Manager + +00:13:40.320 --> 00:13:46.479 +as the basis for Emacs's user interface. Screwlisp is + +00:13:46.480 --> 00:13:52.879 +giving a talk about McCLIM later today, but for present + +00:13:52.880 --> 00:13:55.919 +purposes, just think of it as a super-powered version of + +00:13:55.920 --> 00:14:01.279 +Emacs's concept of interactive functions. It would be a + +00:14:01.280 --> 00:14:04.799 +pretty long-term project in Emacs as it currently exists, + +00:14:04.800 --> 00:14:10.519 +but it would be almost trivial if Emacs were customizable at + +00:14:10.520 --> 00:14:11.599 +the lowest layers via Lisp. + +00:14:11.600 --> 00:14:19.599 +We'll certainly be looking at the practicality of these + +00:14:19.600 --> 00:14:23.839 +kinds of changes as we continue developing Guile-Emacs. + +00:14:23.840 --> 00:14:31.719 +Finally, how can you get involved with and support Guile + +00:14:31.720 --> 00:14:35.999 +Emacs? One way to help is just by trying it out and letting us + +00:14:36.000 --> 00:14:40.519 +know what your experiences are like. There will be a + +00:14:40.520 --> 00:14:44.079 +snapshot available on the Codeberg project site of the + +00:14:44.080 --> 00:14:48.759 +version that I'm using to give this presentation. It will be + +00:14:48.760 --> 00:14:52.719 +available both as a Guix package and as a portable tarball. + +00:14:52.720 --> 00:14:58.799 +This will be more interesting as we get closer to a complete + +00:14:58.800 --> 00:15:05.479 +rebase. We're also always happy to talk to potential + +00:15:05.480 --> 00:15:10.879 +contributors or potential collaborators from other + +00:15:10.880 --> 00:15:11.599 +projects. + +00:15:11.600 --> 00:15:18.159 +We can always use bug reports, and we're interested in what + +00:15:18.160 --> 00:15:21.719 +kind of features people actually want to see in Guile-Emacs. + +00:15:21.720 --> 00:15:27.359 +Guile-Emacs is also being developed by a small worker + +00:15:27.360 --> 00:15:32.159 +cooperative, so donations are a pretty direct way to + +00:15:32.160 --> 00:15:36.039 +support the project. If you do nothing else, I recommend + +00:15:36.040 --> 00:15:40.719 +going to the website and subscribing to our mailing lists so + +00:15:40.720 --> 00:15:45.879 +that you can keep up with news on the project. If you're + +00:15:45.880 --> 00:15:49.239 +watching this at EmacsConf, there will be a Q&A session + +00:15:49.240 --> 00:15:57.080 +immediately following this, and thanks for watching! |