add answers captionsHEADmaster

1 files changed, 720 insertions, 0 deletions

diff --git a/2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--answers.vtt b/2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--answers.vtt
new file mode 100644
index 00000000..510e556e
--- /dev/null
+++ b/2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--answers.vtt
@@ -0,0 +1,720 @@
+WEBVTT
+
+00:00:00.000 --> 00:00:08.119
+All right. Hey, thanks for bearing with us there. We had a
+
+00:00:08.120 --> 00:00:11.239
+couple of bumps in the road, a cross between a couple of
+
+00:00:11.240 --> 00:00:13.479
+different versions of our program that we deliver here,
+
+00:00:13.480 --> 00:00:17.959
+different ways that we bring this stream together between
+
+00:00:17.960 --> 00:00:22.359
+the recorded content that that speakers are putting
+
+00:00:22.360 --> 00:00:26.879
+together in advance in the live content, such as what you're
+
+00:00:26.880 --> 00:00:31.039
+seeing right here. So thanks go to Sacha and Leo, and
+
+00:00:31.040 --> 00:00:34.359
+everybody behind the stages gluing it all together. And
+
+00:00:34.360 --> 00:00:40.199
+we're back here now, and I'm speaking with Robin, who us
+
+00:00:40.200 --> 00:00:42.799
+ready to take on some of your questions and address some of
+
+00:00:42.800 --> 00:00:46.879
+the comments over here on the etherpad. If you want to jump in
+
+00:00:46.880 --> 00:00:51.319
+there, there's links in the chat. And thanks so much, Robin,
+
+00:00:51.320 --> 00:00:53.999
+for your talk. And it's also been a pleasure chatting with
+
+00:00:54.000 --> 00:00:57.919
+you just a little bit over the last couple of months on IRC.
+
+00:00:57.920 --> 00:01:33.319
+Yeah, absolutely. Great meeting you.
+
+00:01:33.320 --> 00:01:37.679
+All right. All right, everyone. I think I am streaming now.
+
+00:01:37.680 --> 00:01:42.439
+So let's look at it. Let's see. I see the IRC scrolling. So
+
+00:01:42.440 --> 00:01:47.199
+let's see where that's going. Yes, the Common Lisp is what I
+
+00:01:47.200 --> 00:01:50.519
+thought would piss people off. And because it's not part of
+
+00:01:50.520 --> 00:01:54.239
+either community, but I think it would be a good compromise
+
+00:01:54.240 --> 00:01:57.839
+for building a Lisp into a language that's more suitable for
+
+00:01:57.840 --> 00:02:01.879
+building large systems like the kind that we are building in
+
+00:02:01.880 --> 00:02:07.279
+Emacs today. I also left out an important part of the talk,
+
+00:02:07.280 --> 00:02:12.079
+which is part of the motivation for transitioning from C to
+
+00:02:12.080 --> 00:02:15.599
+Lisp. And that's the performance characteristics
+
+00:02:15.600 --> 00:02:19.399
+fundamentally change when you get a modern and high
+
+00:02:19.400 --> 00:02:23.559
+performance Lisp system involved. it starts getting less
+
+00:02:23.560 --> 00:02:27.799
+practical to just call out to C to speed up every operation.
+
+00:02:27.800 --> 00:02:31.559
+Among other things, you lose the ability to use more
+
+00:02:31.560 --> 00:02:34.759
+advanced control structures, like the limited
+
+00:02:34.760 --> 00:02:40.039
+continuations. And you also have to pay the overhead of
+
+00:02:40.040 --> 00:02:43.879
+calling out to our foreign function. So it gets to be an
+
+00:02:43.880 --> 00:02:47.879
+increasingly better deal to optimize your list
+
+00:02:47.880 --> 00:02:52.719
+implementation and provide ways for building faster list
+
+00:02:52.720 --> 00:02:55.879
+programs, such as type annotations, once you've gotten
+
+00:02:55.880 --> 00:03:01.479
+over a certain threshold of performance.
+
+NOTE Q: About fibers: My understanding is that the problem with making Elisp concurrent is that none of the data structures (buffer, cons, vector, window etc) are concurrency-safe.  How do fibers help with this?
+
+00:03:01.480 --> 00:03:07.359
+I'm going to look at the pad. Here we go. The first question is
+
+00:03:07.360 --> 00:03:12.519
+about fibers and whether they help with making Elisp
+
+00:03:12.520 --> 00:03:18.279
+concurrent in terms of its data structures. Yes, that's
+
+00:03:18.280 --> 00:03:23.879
+absolutely correct. Fibers by themselves do not provide
+
+00:03:23.880 --> 00:03:26.799
+thread safety for any of the existing Emacs data
+
+00:03:26.800 --> 00:03:32.879
+structures. What they are useful for is building things
+
+00:03:32.880 --> 00:03:38.199
+that don't use Emacs data structures, say a network client
+
+00:03:38.200 --> 00:03:44.559
+that reads input from a stream or in scheme, a port or a stream
+
+00:03:44.560 --> 00:03:49.679
+instead of a buffer. And we can also take a look at options for
+
+00:03:49.680 --> 00:03:54.199
+making more Emacs features concurrency safe or thread
+
+00:03:54.200 --> 00:03:58.079
+safe. For example, we could introduce the idea of a thread
+
+00:03:58.080 --> 00:04:03.039
+local buffer that didn't require locks for sharing between
+
+00:04:03.040 --> 00:04:09.239
+different threads. And I'm not sure how that would develop,
+
+00:04:09.240 --> 00:04:12.319
+but I'm sure the Emacs maintainers already have some ideas
+
+00:04:12.320 --> 00:04:17.519
+in this direction. Fibers will basically provide a
+
+00:04:17.520 --> 00:04:22.159
+high-performance system that you can use apart from
+
+00:04:22.160 --> 00:04:28.079
+ordinary Emacs-less constructs.
+
+NOTE Q: Do you have a rough idea of how much of Guile is written in C?
+
+00:04:28.080 --> 00:04:34.839
+Let's see. We have another question. Emacs is roughly 25% C.
+
+00:04:34.840 --> 00:04:38.839
+How much of Guile is in C?
+
+00:04:38.840 --> 00:04:45.679
+Well, part of my point about C is not so much that there, well,
+
+00:04:45.680 --> 00:04:50.279
+obviously, I phrased it a little provocatively, but the
+
+00:04:50.280 --> 00:04:54.719
+problem is not so much that there is C, but that there is so
+
+00:04:54.720 --> 00:05:00.279
+much C involved in every single layer of the application.
+
+00:05:00.280 --> 00:05:04.559
+So, for example, we're limited in our ability to use tools
+
+00:05:04.560 --> 00:05:08.159
+like limit continuations, which can be used to express
+
+00:05:08.160 --> 00:05:13.599
+buffer local variable binding in a few dozen lines, because
+
+00:05:13.600 --> 00:05:21.839
+Emacs has so much calling back and forth between guile and C,
+
+00:05:21.840 --> 00:05:26.599
+due to so much basic functionality being in primitive C
+
+00:05:26.600 --> 00:05:34.119
+subroutines. So that's one issue apart from the question of
+
+00:05:34.120 --> 00:05:38.359
+how much is in a particular language. To answer the question
+
+00:05:38.360 --> 00:05:45.879
+about Guile, Guile has about 165,000 lines of scheme code
+
+00:05:45.880 --> 00:05:51.599
+and about 160,000 lines of C code, so it's about half and
+
+00:05:51.600 --> 00:05:55.879
+half. And that shouldn't really be surprising given that it
+
+00:05:55.880 --> 00:06:00.359
+is actually focused on low-level things like building a
+
+00:06:00.360 --> 00:06:05.079
+high-performance bytecode compiler, and a just-in-time
+
+00:06:05.080 --> 00:06:09.719
+compiler, and so on, as well as providing its own fairly
+
+00:06:09.720 --> 00:06:14.999
+rich, but still far less complete than Emacs's standard
+
+00:06:15.000 --> 00:06:19.239
+library, in terms of Ice9 and other system libraries
+
+NOTE Q: A Common Lisp implementation for Guile sounds really cool! Is there already work on this underway?
+
+00:06:19.240 --> 00:06:24.359
+shipped with Guile. The next question is on a Common Lisp
+
+00:06:24.360 --> 00:06:27.759
+implementation for Guile, and whether work on it is
+
+00:06:27.760 --> 00:06:33.079
+underway. In fact, work on it is already underway. I've been
+
+00:06:33.080 --> 00:06:36.399
+working on it on and off in my spare time for a couple of years
+
+00:06:36.400 --> 00:06:40.039
+now. I've gotten, I think, a couple of chapters of the
+
+00:06:40.040 --> 00:06:43.519
+hyperspectin, if you want to measure it that way. But I've
+
+00:06:43.520 --> 00:06:51.719
+been focusing my work more on research and on what we need to
+
+00:06:51.720 --> 00:06:57.399
+do to have a LISP environment, a polyglot LISP environment,
+
+00:06:57.400 --> 00:07:02.759
+wherein the features of Common Lisp and Scheme and Emacs
+
+00:07:02.760 --> 00:07:08.919
+Lisp can all work easily and ergonomically together. So
+
+00:07:08.920 --> 00:07:13.879
+this involves things like the question of Lisps having
+
+00:07:13.880 --> 00:07:22.079
+Lisp1s versus Lisp2s. That is, a Lisp1-like scheme has one
+
+00:07:22.080 --> 00:07:27.599
+namespace, like every variable is a single name that can
+
+00:07:27.600 --> 00:07:31.999
+refer to one value, whereas in Lisp2s like EmacsLisp,
+
+00:07:32.000 --> 00:07:37.399
+symbols can have different definitions as functions and as
+
+00:07:37.400 --> 00:07:41.119
+variables, as well as other namespaces like property
+
+00:07:41.120 --> 00:07:45.719
+lists. So Kent Pittman has some interesting thoughts on
+
+00:07:45.720 --> 00:07:51.039
+this that I've been looking into. Another issue is the
+
+00:07:51.040 --> 00:07:57.519
+interaction between package and module systems. So I don't
+
+00:07:57.520 --> 00:08:01.839
+have really anything ready to publish just yet on this, but I
+
+00:08:01.840 --> 00:08:05.279
+have been looking into the background issues of
+
+00:08:05.280 --> 00:08:08.119
+integrating this into Guile in a useful way.
+
+00:08:08.120 --> 00:08:15.719
+And let's see, one other thing I was going to mention.
+
+00:08:15.720 --> 00:08:27.679
+Okay, I've lost it. But yeah, there is some work already. And
+
+00:08:27.680 --> 00:08:30.399
+if people are interested in moving Emacs in this direction,
+
+00:08:30.400 --> 00:08:34.479
+then we'll certainly start working on it in earnest.
+
+NOTE Q: Did switching from guile 2 to 3 give any performance benefits?
+
+00:08:34.480 --> 00:08:41.119
+Another question, did switching from Guile 2 to 3 give any
+
+00:08:41.120 --> 00:08:46.279
+performance benefits? Well, honestly, we're not really
+
+00:08:46.280 --> 00:08:50.759
+benchmarking stuff here because Guile Emacs has so much
+
+00:08:50.760 --> 00:08:55.759
+overhead from structuring the compiler to closely conform
+
+00:08:55.760 --> 00:08:59.879
+to Emacs in terms of like even things as simple as metadata
+
+00:08:59.880 --> 00:09:03.879
+layout for variable information.
+
+00:09:03.880 --> 00:09:11.999
+So I haven't actually noticed a perceptual change. I would
+
+00:09:12.000 --> 00:09:15.359
+guess based on the Gabriel benchmark results that is
+
+00:09:15.360 --> 00:09:21.399
+benefited from what somewhat from Gal 3's performance
+
+00:09:21.400 --> 00:09:27.479
+improvements but for Emacs I just don't know yet and working
+
+00:09:27.480 --> 00:09:30.199
+on the compiler's code generation and lowering the
+
+00:09:30.200 --> 00:09:33.719
+overhead is going to be the thing that provides the most
+
+00:09:33.720 --> 00:09:37.319
+return for improving that aspect of Gal Emacs.
+
+00:09:37.320 --> 00:09:54.079
+Let's see, I see SICL mentioned here, as well as SPCL. And it
+
+00:09:54.080 --> 00:09:56.919
+could certainly help with the implementation of
+
+00:09:56.920 --> 00:10:01.519
+Commonwealth and Guile, because a lot of the basic stuff is
+
+00:10:01.520 --> 00:10:05.559
+just providing a new interface to some bit of
+
+00:10:05.560 --> 00:10:08.879
+functionality. Like the sequence library, it's mostly
+
+00:10:08.880 --> 00:10:13.279
+stuff that we already have through SR5 and so on. The
+
+00:10:13.280 --> 00:10:16.879
+difficult, well, not the difficult but the time consuming
+
+00:10:16.880 --> 00:10:21.599
+parts are going to be all the little DSL sitcom on this path
+
+00:10:21.600 --> 00:10:26.999
+packed up inside it like pretty printing format loop and so
+
+00:10:27.000 --> 00:10:32.359
+on. It's for those high-level features that I think we could
+
+00:10:32.360 --> 00:10:34.959
+potentially share code with other Common Lisp
+
+00:10:34.960 --> 00:10:39.039
+implementations. And Common Lisp implementations do tend
+
+00:10:39.040 --> 00:10:43.239
+to be permissively licensed, SPCL's public domain, for
+
+00:10:43.240 --> 00:10:46.439
+example, so there's no barrier to sharing code with them.
+
+NOTE Q: Do you know if the Emacs maintainers are interested in switching to Guile as the engine for Emacs Lisp?
+
+00:10:46.440 --> 00:10:52.719
+There's another question about whether the Emacs
+
+00:10:52.720 --> 00:10:55.679
+maintainers are interested in switching to Guile as the
+
+00:10:55.680 --> 00:10:59.199
+engine for Emacs Lisp. I can't speak for the current
+
+00:10:59.200 --> 00:11:05.439
+maintainers. I can say that people have talked to previous
+
+00:11:05.440 --> 00:11:10.439
+Emacs maintainers about the whole idea, and their attitude
+
+00:11:10.440 --> 00:11:15.479
+was generally cautiously optimistic. As in, it's not
+
+00:11:15.480 --> 00:11:18.799
+something they, it's somewhat political, they didn't want
+
+00:11:18.800 --> 00:11:23.479
+to get into it, but they didn't think that it was a bad idea,
+
+00:11:23.480 --> 00:11:25.919
+and they wanted to know more about how it might evolve in the
+
+00:11:25.920 --> 00:11:31.879
+future. I can comment that Eli Zaretsky, who I believe is the
+
+00:11:31.880 --> 00:11:36.879
+current Emacs maintainer, is very concerned about
+
+00:11:36.880 --> 00:11:44.679
+cross-platform compatibility. And so if I can guess at his
+
+00:11:44.680 --> 00:11:48.519
+priorities correctly, I think that that's something that
+
+00:11:48.520 --> 00:11:52.599
+we'll have to make sure is rock solid before we propose any
+
+00:11:52.600 --> 00:11:58.359
+kind of upstreaming of Gala Emacs. but in general
+
+00:11:58.360 --> 00:12:03.719
+maintainers have been cautious but curious. So I just
+
+00:12:03.720 --> 00:12:06.719
+wanted to break in and note at this point that as lives I
+
+00:12:06.720 --> 00:12:09.519
+didn't sorry I couldn't do so more gracefully while we were
+
+00:12:09.520 --> 00:12:13.439
+still on stream but I wanted to let you know that just as of 10
+
+00:12:13.440 --> 00:12:17.399
+seconds ago or so we've had to cut away into our next talk but
+
+00:12:17.400 --> 00:12:22.199
+we can keep going here as long as we like. Okay, let's wrap up.
+
+00:12:22.200 --> 00:12:25.399
+There's only a couple questions left on the pad, so I'll
+
+00:12:25.400 --> 00:12:29.999
+answer those, and then I'll be available on IRC. So, the next
+
+NOTE Q: Do you think guile-emacs will be able to use or (collaborate with) some of the other awesome projects around Emacs Lisp?
+
+00:12:30.000 --> 00:12:33.319
+question is whether Guile Emacs will be able to collaborate
+
+00:12:33.320 --> 00:12:35.959
+with projects like Gypsum and
+
+00:12:35.960 --> 00:12:44.319
+the native compilation projects or the pre-scheme
+
+00:12:44.320 --> 00:12:48.039
+efforts. Oh, yes, that is one of the things I forgot to bring
+
+00:12:48.040 --> 00:12:53.199
+up in my talk. So, first of all, Gypsum is approaching a
+
+00:12:53.200 --> 00:12:58.199
+similar idea from a different direction. And we clearly
+
+00:12:58.200 --> 00:13:03.919
+have a different focus. My focus is on improving Emacs Lisp
+
+00:13:03.920 --> 00:13:09.279
+and making Emacs itself better by integrating Guile Elisp
+
+00:13:09.280 --> 00:13:15.159
+and Emacs, rather than replacing eLisp or deprecating it in
+
+00:13:15.160 --> 00:13:20.159
+any way. But given gypsum's requirements, I do think that we
+
+00:13:20.160 --> 00:13:26.439
+could share a lot of code required for emulating basic Emacs
+
+00:13:26.440 --> 00:13:29.839
+functionality. And this could even become interesting if
+
+00:13:29.840 --> 00:13:35.799
+we get to the point of rewriting parts of Emacs in Lisp. With
+
+00:13:35.800 --> 00:13:41.279
+respect to the native compilation effort, I'm familiar
+
+00:13:41.280 --> 00:13:45.879
+with it. I'm not that impressed with the results of it. It's a
+
+00:13:45.880 --> 00:13:52.359
+very impressive effort, but as far as I can tell, it's
+
+00:13:52.360 --> 00:13:57.239
+accelerating a bytecode interpreter that just simply has
+
+00:13:57.240 --> 00:14:02.719
+an out-of-date design, to be quite blunt. It's possible
+
+00:14:02.720 --> 00:14:08.919
+that Emacs's JIT has ideas that Guile should adopt, like
+
+00:14:08.920 --> 00:14:14.039
+perhaps libgccjit might perhaps be better than GNU
+
+00:14:14.040 --> 00:14:16.999
+Lightning, which is a relatively simple JIT that Guile
+
+00:14:17.000 --> 00:14:17.639
+uses.
+
+00:14:17.640 --> 00:14:25.839
+But it doesn't have to have a direct relationship to Guile
+
+00:14:25.840 --> 00:14:31.159
+Emacs. And as far as pre-scheme goes, I have been watching
+
+00:14:31.160 --> 00:14:36.199
+Flat Watson's work on pre-scheme with great interest
+
+00:14:36.200 --> 00:14:39.999
+because Scheme 48 used to be my favorite implementation.
+
+00:14:40.000 --> 00:14:44.919
+And I do think that it could be, it's a tool that we should look
+
+00:14:44.920 --> 00:14:47.879
+at when we're thinking about moving functionality into
+
+00:14:47.880 --> 00:14:53.199
+Lisp and could certainly make it easier to upstream some of
+
+00:14:53.200 --> 00:14:54.519
+the work we may end up doing.
+
+00:14:54.520 --> 00:15:04.199
+All right, do we have more questions?
+
+NOTE Q: SBCL, ...You mentioned Robert Strandh's SICL along with SBCL---does that work help with the implementation of CL in Guile?
+
+00:15:04.200 --> 00:15:13.159
+There's a question about SICL and SBCL. I think I answered
+
+00:15:13.160 --> 00:15:17.519
+that earlier. It should help us implement Common Lisp when
+
+00:15:17.520 --> 00:15:24.999
+it comes to high-level features and the various large
+
+00:15:25.000 --> 00:15:28.759
+subcomponents of Common Lisp. Another important factor is
+
+00:15:28.760 --> 00:15:32.279
+that Guile already has decent support for the Common Lisp
+
+00:15:32.280 --> 00:15:35.799
+object system. Without that, it would be far more
+
+00:15:35.800 --> 00:15:41.919
+difficult. But I do expect that we can share code with other
+
+00:15:41.920 --> 00:15:44.799
+Common Lisp implementations. I've personally rated
+
+00:15:44.800 --> 00:15:49.199
+Common Lisp compiler code when working on Guile Hoot, for
+
+00:15:49.200 --> 00:15:52.959
+example. So there are definitely places where they can
+
+00:15:52.960 --> 00:15:54.039
+contribute.
+
+00:15:54.040 --> 00:16:02.839
+Regarding the Hoot project and its relationship to
+
+00:16:02.840 --> 00:16:11.079
+Galimax, it's a purely speculative thing. First of all,
+
+00:16:11.080 --> 00:16:17.079
+Hoot is only tested on Scheme-to-WebAssembly
+
+00:16:17.080 --> 00:16:22.599
+compilations. I've heard some suggestions that some uses
+
+00:16:22.600 --> 00:16:26.439
+of Tree.io may not be compatible with the Hoot compiler. I'm
+
+00:16:26.440 --> 00:16:29.999
+not sure if that's the case or not.
+
+00:16:30.000 --> 00:16:41.199
+But it is a complete enough project that if Emacs is, say, 90%
+
+00:16:41.200 --> 00:16:45.119
+Lisp, there's only a few thousand lines of C code to
+
+00:16:45.120 --> 00:16:49.159
+implement, then it would be entirely practical to compile
+
+00:16:49.160 --> 00:16:54.159
+Emacs WebAssembly, as long as we had a back end, like one
+
+00:16:54.160 --> 00:16:58.119
+based on the browser's document object model, or some sort
+
+00:16:58.120 --> 00:17:04.439
+of graphical interface through WASI. And that may have some
+
+00:17:04.440 --> 00:17:07.359
+interesting applications for portability to unusual
+
+00:17:07.360 --> 00:17:11.359
+platforms. It may even bring performance advantages in
+
+00:17:11.360 --> 00:17:18.959
+cases where the WebAssembly implementation is connected
+
+00:17:18.960 --> 00:17:22.759
+to a tracing just-in-time compiler, because that may be
+
+00:17:22.760 --> 00:17:26.839
+more appropriate to the high level of dynamism the Emacs
+
+00:17:26.840 --> 00:17:32.439
+list has than the kind of simple template JITs that both
+
+00:17:32.440 --> 00:17:34.519
+Emacs and Guile are using.
+
+00:17:34.520 --> 00:17:39.799
+What a fascinating point. Just to break into active
+
+00:17:39.800 --> 00:17:43.999
+listening a little so this doesn't, to you, feel like you're
+
+00:17:44.000 --> 00:17:46.919
+talking to yourself. I can see from chat and the questions
+
+00:17:46.920 --> 00:17:51.439
+still coming in, you know, comments. You know, it isn't, but
+
+00:17:51.440 --> 00:17:54.999
+I just want you to be able to hear and feel that. Yeah, great,
+
+00:17:55.000 --> 00:18:00.679
+great point there. All right. Thank you. And yes, if there
+
+00:18:00.680 --> 00:18:04.679
+are more questions, keep throwing them at me. I should
+
+00:18:04.680 --> 00:18:07.999
+probably also mention I will have to jump out myself, but the
+
+00:18:08.000 --> 00:18:10.799
+recording will automatically end when we all jump out or
+
+00:18:10.800 --> 00:18:15.199
+just drop a note anywhere, ping me, whatever. And I'll come
+
+00:18:15.200 --> 00:18:18.439
+along and shut off the recording and we'll trim it up before
+
+00:18:18.440 --> 00:18:21.879
+we publish it. I'm looking forward to reading through
+
+00:18:21.880 --> 00:18:30.199
+anything I do miss. Thank you. Sounds good.
+
+00:18:30.200 --> 00:19:08.439
+All right, I'm not seeing changes in the etherpad. So I'm
+
+00:19:08.440 --> 00:19:14.999
+going to close this in maybe 30 seconds if there are no more
+
+00:19:15.000 --> 00:19:21.159
+additions. Thanks, everyone, for the interesting and very
+
+00:19:21.160 --> 00:19:26.399
+pointed questions on some of the most significant areas. I
+
+00:19:26.400 --> 00:19:31.919
+appreciate everyone's feedback. I'm glad this provoked so
+
+00:19:31.920 --> 00:19:33.679
+much curiosity in people.
+
+00:19:33.680 --> 00:19:44.519
+Thank you, janneke.
+
+00:19:44.520 --> 00:19:51.439
+All right, I think we are done with the Q&A session, so I'm
+
+00:19:51.440 --> 00:19:57.199
+going to close this BBB and we can continue with the rest of
+
+00:19:57.200 --> 00:19:58.719
+EmacsConf.
+
+00:19:58.720 --> 00:20:10.160
+You are currently the only person in this conference.