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.