diff options
Diffstat (limited to '2024/captions/emacsconf-2024-rust--an-experimental-emacs-core-in-rust--troy-hinckley--answers.vtt')
| -rw-r--r-- | 2024/captions/emacsconf-2024-rust--an-experimental-emacs-core-in-rust--troy-hinckley--answers.vtt | 926 |
1 files changed, 926 insertions, 0 deletions
diff --git a/2024/captions/emacsconf-2024-rust--an-experimental-emacs-core-in-rust--troy-hinckley--answers.vtt b/2024/captions/emacsconf-2024-rust--an-experimental-emacs-core-in-rust--troy-hinckley--answers.vtt new file mode 100644 index 00000000..1b881325 --- /dev/null +++ b/2024/captions/emacsconf-2024-rust--an-experimental-emacs-core-in-rust--troy-hinckley--answers.vtt @@ -0,0 +1,926 @@ +WEBVTT + +00:00:00.000 --> 00:00:06.519 +Okay, so I'm going to look at some of the questions showing up + +00:00:06.520 --> 00:00:08.499 +in the etherpad we got here. + +NOTE Q: Have you considered using CRDTs to share buffers between threads and merge any concurrent edits automatically? + +00:00:08.500 --> 00:00:09.439 +It says, have you considered + +00:00:09.440 --> 00:00:12.799 +using a CRDT to share buffers between threads and merge any + +00:00:12.800 --> 00:00:16.039 +concurrent edits automatically? So I have looked at that. + +00:00:16.040 --> 00:00:20.559 +And the problem with CRDTs is that even though they give you a + +00:00:20.560 --> 00:00:22.839 +mathematically correct answer when you're trying to merge + +00:00:22.840 --> 00:00:26.479 +two conflicts, it's not always a useful answer. Like, it's + +00:00:26.480 --> 00:00:29.199 +not coherent. If you have two things trying to edit the same + +00:00:29.200 --> 00:00:31.359 +thing, there's no good way to resolve that. And so they + +00:00:31.360 --> 00:00:33.559 +really work well when you have two people working live, both + +00:00:33.560 --> 00:00:35.639 +editing the same document, because they can fix any + +00:00:35.640 --> 00:00:37.199 +particular issues like that, like you would with Google + +00:00:37.200 --> 00:00:39.919 +Docs. But you have different packages that aren't aware of + +00:00:39.920 --> 00:00:42.159 +each other, and you're going to run into problems. And so + +00:00:42.160 --> 00:00:44.999 +this is something, if you read from the Xi editor, which was + +00:00:45.000 --> 00:00:48.039 +one of the first ones to use CRDTs, in the retrospective, he + +00:00:48.040 --> 00:00:52.359 +talks about how they had this problem, where the CRDTs They + +00:00:52.360 --> 00:00:53.999 +give you an answer, but it's not always an answer that's + +00:00:54.000 --> 00:00:59.079 +useful. And so I feel like locks at least are going to make it. + +00:00:59.080 --> 00:01:00.439 +It's not going to be as efficient if you have a whole bunch of + +00:01:00.440 --> 00:01:02.319 +packages, but I don't imagine there's going to be a ton of + +00:01:02.320 --> 00:01:04.799 +those. It can actually, I think it'll be more useful in + +00:01:04.800 --> 00:01:05.873 +practice. + +NOTE Q: Why hosted on GitHub? GitHub is nonfree. Is it possible to report bugs/send patches without using GitHub? + +00:01:05.874 --> 00:01:11.239 +I host on GitHub because that's what I know. + +00:01:11.240 --> 00:01:13.239 +If there's a way to host it on somewhere else, I'd be + +00:01:13.240 --> 00:01:15.439 +interested in doing that. If you're interested in setting + +00:01:15.440 --> 00:01:17.799 +patches without using GitHub, you could always send an + +00:01:17.800 --> 00:01:22.959 +email. I'm more than happy to accept email patches. + +NOTE Q: Do you think it's possible to achieve 100% compatibility with current Emacs code? + +00:01:22.960 --> 00:01:24.959 +Do you think it's possible to achieve with the current Emacs + +00:01:24.960 --> 00:01:29.719 +code? I do. I think, I think you can do that. Um, like I said, + +00:01:29.720 --> 00:01:33.279 +there's a couple things inside there that are intentional + +00:01:33.280 --> 00:01:37.919 +breaks with existing Emacs code. And some of those being + +00:01:37.920 --> 00:01:43.159 +like functions are immutable. As well as having data shared + +00:01:43.160 --> 00:01:44.759 +switch between different threads, which means there's + +00:01:44.760 --> 00:01:46.599 +going to be some copying going on. So there's going to be + +00:01:46.600 --> 00:01:48.399 +subtle things that are going to be different. And we've + +00:01:48.400 --> 00:01:50.359 +really got to think about those intentionally, but I'm + +00:01:50.360 --> 00:01:54.519 +really going for bug compatibility with GNU Emacs so that + +00:01:54.520 --> 00:01:57.159 +you can take an existing Elisp package and just run it and it + +00:01:57.160 --> 00:01:59.879 +just works, 'cause I think that's one of the big strengths of + +00:01:59.880 --> 00:02:03.399 +the Emacs ecosystem is the millions of lines of Elisp that + +00:02:03.400 --> 00:02:07.479 +people have written. + +00:02:07.480 --> 00:02:11.912 +Um, So I'm not, okay... + +NOTE Q: so you're re-implementing elisp in rust? have you considered using a more modern lisp, such as scheme? [11:03] + +00:02:11.913 --> 00:02:14.279 +So since you're re-implementing Elisp and + +00:02:14.280 --> 00:02:17.039 +Rust, have you considered using more modern Lisp such as + +00:02:17.040 --> 00:02:20.919 +Scheme? So I'm not re-implementing Elisp and Rust. I'm + +00:02:20.920 --> 00:02:25.439 +re-implementing the C in Rust. In fact, I would like to make + +00:02:25.440 --> 00:02:30.479 +more of the core that's written in C in Elisp instead of C or + +00:02:30.480 --> 00:02:33.839 +Rust, because then it's actually introspectible. There's + +00:02:33.840 --> 00:02:38.719 +a talk by Tom Tromney that he gave a while ago about Emacs + +00:02:38.720 --> 00:02:42.239 +should be Emacs Lisp. I kind of like that philosophy, + +00:02:42.240 --> 00:02:44.799 +that as much of it as should be Elisp as possible, and we + +00:02:44.800 --> 00:02:48.079 +should only have C or Rust or some systems level language for + +00:02:48.080 --> 00:02:52.319 +really low-level stuff. Using a more modern LISP such as + +00:02:52.320 --> 00:02:54.839 +Scheme. I know there's, I mean, there's two talks, I think, + +00:02:54.840 --> 00:02:58.239 +in this conference about using Scheme inside Emacs. And I + +00:02:58.240 --> 00:03:00.719 +looked at this at one point about what if you wrote it inside + +00:03:00.720 --> 00:03:03.919 +Common LISP, because that's also has some really low level + +00:03:03.920 --> 00:03:05.879 +details. And then you could go from Elisp down to Common + +00:03:05.880 --> 00:03:09.199 +Lisp. But the problem is, is under the hood, you still need a + +00:03:09.200 --> 00:03:12.559 +systems language. You can't, you still need either C or Rust + +00:03:12.560 --> 00:03:15.639 +or something underneath the Common Lisp to implement the + +00:03:15.640 --> 00:03:17.799 +primitives. And so it's not going to give you just two + +00:03:17.800 --> 00:03:19.719 +languages, you know, you'll have three. You'll have the + +00:03:19.720 --> 00:03:24.919 +elisp, common lisp, and C under the hood. And so in this case + +00:03:24.920 --> 00:03:29.559 +we just have the two. We have the Elisp and the rest. + +00:03:29.560 --> 00:03:42.999 +All right that's all the questions I see there. Let + +00:03:43.000 --> 00:03:54.079 +me go look at... Okay, + +00:03:54.080 --> 00:04:01.399 +so I see into the chat. + +NOTE Q: Do you have specific features from the Rust compiler that are missing (or are nightly-only) that you would take advantage of? + +00:04:01.400 --> 00:04:03.839 +Does it features from the Rust compiler that are missing + +00:04:03.840 --> 00:04:06.239 +that way you would take advantage of? Oh, that is a great + +00:04:06.240 --> 00:04:10.679 +question. Um, there's a handful of them. Uh, I should've + +00:04:10.680 --> 00:04:13.599 +written down a list of these. One of them is Polonius, which + +00:04:13.600 --> 00:04:17.959 +is the new borrow checker because we're trying to be used + +00:04:17.960 --> 00:04:21.759 +lifetime to track our objects. We often run into situations + +00:04:21.760 --> 00:04:24.239 +where we've kind of got a hack around things because the + +00:04:24.240 --> 00:04:26.199 +limitations with the borrow checker. And so I have a whole + +00:04:26.200 --> 00:04:29.559 +bunch of like notes inside there about where. A better + +00:04:29.560 --> 00:04:34.959 +Polonius would help inside there and help ease some of the + +00:04:34.960 --> 00:04:40.599 +issues. Another thing is enum variances types, because + +00:04:40.600 --> 00:04:42.999 +right now we have an object which is defined as a big enum that + +00:04:43.000 --> 00:04:46.079 +had all the possible objects, but if we want to have a subset + +00:04:46.080 --> 00:04:47.479 +of those objects or just pass in one of those objects, we've + +00:04:47.480 --> 00:04:50.079 +got to define a new struct. And so we have a whole bunch of + +00:04:50.080 --> 00:04:52.839 +boilerplate code to define that all out. And if we had + +00:04:52.840 --> 00:04:56.719 +variances types, that would make the code a lot easier. + +00:04:56.720 --> 00:05:00.079 +Another one is the allocator API. Right now we're kind of + +00:05:00.080 --> 00:05:02.479 +working around it, but ultimately we're going to need our + +00:05:02.480 --> 00:05:07.719 +own allocator. And the allocator API is still nightly only. + +00:05:07.720 --> 00:05:10.919 +So there's a couple more. I'll look at that more, but that's a + +00:05:10.920 --> 00:05:24.279 +great question. + +00:05:24.280 --> 00:05:26.879 +Let's see. + +NOTE Q: Can remacs be reused? + +00:05:26.880 --> 00:05:30.799 +Okay. I see a question you might not have noticed just asking + +00:05:30.800 --> 00:05:37.159 +about reuse of Remacs. Oh, yes, so I have reused some of Remacs + +00:05:37.160 --> 00:05:40.159 +code, and some taken, like I mentioned, taken some of their + +00:05:40.160 --> 00:05:45.319 +ideas, but ultimately we're using a different model + +00:05:45.320 --> 00:05:49.439 +because under the hood in Remacs, everything is just defined + +00:05:49.440 --> 00:05:53.799 +as an opaque external type that's defined inside Emacs and + +00:05:53.800 --> 00:05:56.159 +so it just pulls those in interacts with those and passes + +00:05:56.160 --> 00:05:58.879 +them back into C. We're trying to see what we can do if we + +00:05:58.880 --> 00:06:02.279 +say okay we're not going to take the same... So they're bound to + +00:06:02.280 --> 00:06:06.839 +the implementation details of Emacs, and we don't want to do + +00:06:06.840 --> 00:06:09.559 +that. We've re-implemented all the core types + +00:06:09.560 --> 00:06:12.559 +ourselves. So that means that we can't just take the + +00:06:12.560 --> 00:06:16.559 +Remacs code one for one and use it in our project, but we can + +00:06:16.560 --> 00:06:18.799 +take a lot of their ideas. I've spent some time reading + +00:06:18.800 --> 00:06:20.439 +through their documentation, different things about how + +00:06:20.440 --> 00:06:23.856 +they approached strings and GC + +00:06:23.857 --> 00:06:24.759 +and different stuff like that. + +00:06:24.760 --> 00:07:23.599 +Looks like all the questions. + +NOTE Q: What are you thoughts on the GUI layer. Any plans on how to reimplement it? + +00:07:23.600 --> 00:07:26.199 +Okay, so another question. What are your thoughts on the GUI + +00:07:26.200 --> 00:07:30.959 +layer? Any plans on how to reimplement it? This is something + +00:07:30.960 --> 00:07:34.079 +I've thought a lot about, but I still don't have a solid plan + +00:07:34.080 --> 00:07:37.253 +for. I'm not really a GUI person. I mostly work with + +00:07:37.254 --> 00:07:42.719 +low-level. And so my two thoughts is you can go the GTK route. + +00:07:42.720 --> 00:07:45.519 +There's Rust bindings for that. That's well understood. + +00:07:45.520 --> 00:07:48.319 +It's got a good support. But there's also some interesting + +00:07:48.320 --> 00:07:53.919 +projects to try and do GUI in Rust, native Rust, and have it + +00:07:53.920 --> 00:07:57.399 +use Rust idioms and stuff like that. And so those are things + +00:07:57.400 --> 00:08:01.439 +like Druid and there's eGUI and a bunch of those that are that + +00:08:01.440 --> 00:08:05.359 +way. And I've never used one of them, but I'd be interested to + +00:08:05.360 --> 00:08:08.879 +try that out first and see how well does this work and how well + +00:08:08.880 --> 00:08:21.239 +supported is this doing a Rust-first GUI. + +NOTE Q: If money could fix the problem, how much would it cost to ship this with feature parity before 2026? + +00:08:21.240 --> 00:08:23.639 +If money could fix the problem, how much would it cost to ship + +00:08:23.640 --> 00:08:28.399 +this with feature parity before 2026? Ooh, in a year. Uh, + +00:08:28.400 --> 00:08:32.079 +that's a good question. Even if we had the money, it would + +00:08:32.080 --> 00:08:36.639 +take more than just me, even if I was working on it full time. + +00:08:36.640 --> 00:08:40.630 +Um, I don't know. That's a good question. + +00:08:40.631 --> 00:08:41.769 +I would think it would take a team + +00:08:41.770 --> 00:08:45.239 +of at least a handful of people to get this + +00:08:45.240 --> 00:08:48.559 +shipping within one year. Because there's still a lot of + +00:08:48.560 --> 00:08:50.759 +work to do. And even once you have everything implemented, + +00:08:50.760 --> 00:08:55.119 +there's a lot of bug finding and smoothing it out so that it + +00:08:55.120 --> 00:08:57.519 +runs as well as Emacs, which has been, you know, battle + +00:08:57.520 --> 00:08:58.359 +tested for a long time. + +00:08:58.360 --> 00:09:06.599 +Um, okay, so this might be a good moment for me to break in and + +00:09:06.600 --> 00:09:09.039 +just say that we've got about 10 minutes left before we + +00:09:09.040 --> 00:09:12.519 +resume new talks on on both tracks. Of course, we're happy to + +00:09:12.520 --> 00:09:18.119 +keep this. This chat open and keep the recording going here, + +00:09:18.120 --> 00:09:21.599 +which will share after the conference as long as as long as + +00:09:21.600 --> 00:09:28.349 +there's discussion here. Thank you. + +NOTE GObject implementation + +00:09:28.350 --> 00:09:29.119 +GTK project has + +00:09:29.120 --> 00:09:31.079 +automatic binding with a framework called GObject + +00:09:31.080 --> 00:09:33.599 +introspection, which is what I'm using for gypsum project. + +00:09:33.600 --> 00:09:35.959 +Probably Rust has a G object implementation, which you can + +00:09:35.960 --> 00:09:39.119 +use. Yeah, I know it has some GTK bindings. Um, I'm not sure if + +00:09:39.120 --> 00:09:41.954 +it's specifically GObject, but that's a good path + +00:09:41.955 --> 00:09:44.335 +because I feel like the problem + +00:09:44.336 --> 00:09:46.759 +with the Rust GUIs is that they're all + +00:09:46.760 --> 00:09:50.359 +very new. And so, you know, everything works in a demo, but + +00:09:50.360 --> 00:09:52.319 +you need something that can work across all different + +00:09:52.320 --> 00:09:54.319 +devices and all different platforms and have really good + +00:09:54.320 --> 00:09:56.599 +support and good accessibility and stuff like that. + +NOTE Q: elisp is implemented in c, so if you're not implementing elisp in rust, are you using/keeping the c implementation of elisp? + +00:09:56.600 --> 00:10:03.399 +All right, Elisp is implemented in C. So if you're not + +00:10:03.400 --> 00:10:07.359 +implementing Elisp in Rust, we're keeping the C + +00:10:07.360 --> 00:10:13.639 +implementation of Elisp. So let me see if I can do a better job + +00:10:13.640 --> 00:10:18.439 +of explaining this. So inside Emacs, you have about a + +00:10:18.440 --> 00:10:21.519 +million lines of Elisp. And underneath that, you have the C, + +00:10:21.520 --> 00:10:24.079 +which is the primitives everything's implemented yet. And + +00:10:24.080 --> 00:10:27.079 +so we're keeping all of the Elisp, and we're just taking that + +00:10:27.080 --> 00:10:30.559 +C layer and replacing it with Rust. And so when you call a + +00:10:30.560 --> 00:10:33.079 +built-in function, it's calling into a Rust function + +00:10:33.080 --> 00:10:40.079 +instead of a C function under the hood. So all the Elisp stays + +00:10:40.080 --> 00:10:42.679 +Elisp, but the C becomes Rust. + +NOTE Clarifying rewriting Elisp in Rust + +00:10:42.680 --> 00:10:54.599 +So looking at the IRC chat, it feels to me like maybe there's a + +00:10:54.600 --> 00:10:59.159 +little bit of confusion around what do we mean when we say + +00:10:59.160 --> 00:11:04.839 +rewriting Elisp in Rust, right? I think there are some + +00:11:04.840 --> 00:11:07.399 +people that are like, A, we're reinventing ELISP, and + +00:11:07.400 --> 00:11:09.679 +there's other people that are like, no, we're trying to be + +00:11:09.680 --> 00:11:12.879 +byte-for-byte compatible with Rust. + +00:11:12.880 --> 00:11:17.500 +So some people are questioning your no answer on that. + +00:11:17.501 --> 00:11:20.000 +Aren't you really, maybe, is what I'm reading in there. + +00:11:20.001 --> 00:11:21.769 +Do you want to respond to that? + +00:11:21.770 --> 00:11:26.119 +Yeah, I'm trying to think about how I can make this + +00:11:26.120 --> 00:11:29.559 +clearer. So the Elisp stays Elisp. We're not changing the + +00:11:29.560 --> 00:11:33.239 +Elisp at all, or at least very minimally. We want to be able to + +00:11:33.240 --> 00:11:36.519 +take, like I said, bug compatible. So whatever works inside + +00:11:36.520 --> 00:11:39.999 +existing Emacs, you can take all the Lisp and you can run it in + +00:11:40.000 --> 00:11:43.599 +Rune and it works the same. So the Elisp stays the same. It's + +00:11:43.600 --> 00:11:47.119 +just the under the hood core that is getting replaced. And + +00:11:47.120 --> 00:11:49.199 +this in turn adds some new features such as + +00:11:49.200 --> 00:11:52.799 +multi-threading. So it's not exactly compatible, but + +00:11:52.800 --> 00:11:55.559 +you should be able to use your existing code and the Elisp will + +00:11:55.560 --> 00:12:00.639 +stay Elisp. So the idea is that anything that I've written as + +00:12:00.640 --> 00:12:04.559 +an Emacs user, my config, my custom packages, whatever it + +00:12:04.560 --> 00:12:08.999 +may be, that's all going to be valid code. If you take, you + +00:12:09.000 --> 00:12:13.163 +know, the Elisp implementation as being the C code + +00:12:13.164 --> 00:12:15.745 +and the parts of Elisp written in Elisp + +00:12:15.746 --> 00:12:18.448 +that represent opportunity space + +00:12:18.449 --> 00:12:20.799 +thinking about Rust as an implementation language... + +00:12:20.800 --> 00:12:24.479 +Okay fine. You know, you can make a semantic argument, okay + +00:12:24.480 --> 00:12:25.995 +we're re-implementing, we're creating + +00:12:25.996 --> 00:12:29.018 +an alternate implementation of Elisp + +00:12:29.019 --> 00:12:31.639 +but what Elisp is isn't the problem + +00:12:31.640 --> 00:12:35.039 +space here. That's a fixed, a given, if you will. + +00:12:35.040 --> 00:12:36.065 +Is that all right? + +00:12:36.066 --> 00:12:39.199 +That's a good way of saying it. Okay. Yeah, what you + +00:12:39.200 --> 00:12:42.559 +said makes sense. I was kind of responding to some comments, + +00:12:42.560 --> 00:12:44.959 +like I'm not sure it connected for everybody. Makes a lot of + +00:12:44.960 --> 00:12:47.399 +sense. Yeah, I wasn't sure how much I needed to expand on that + +00:12:47.400 --> 00:12:51.119 +and explain that, but I appreciate you jumping in. + +00:12:51.120 --> 00:12:57.907 +Um, okay. So if I were just going to, but... + +NOTE Q: Will your Rust implementation also be able to run Emacs bytecode? Or are you implementing it at the Lisp level? + +00:12:57.908 --> 00:13:02.239 +Will your Rust implementation also be able to run Emacs bytecode or the + +00:13:02.240 --> 00:13:04.359 +implemented at the Lisp level? So I already have a bytecode + +00:13:04.360 --> 00:13:06.759 +interpreter inside there that runs the existing Elisp + +00:13:06.760 --> 00:13:09.519 +bytecode. And so that was one of the first things I did was + +00:13:09.520 --> 00:13:11.679 +bootstrap the interpreter and then bootstrap the bytecode + +00:13:11.680 --> 00:13:14.999 +engine. And so we compile, we use the... because the bytecode + +00:13:15.000 --> 00:13:19.079 +compiler is written in Emacs Lisp. So you bootstrap that + +00:13:19.080 --> 00:13:22.919 +and it gives you the Emacs bytecode. I have a bytecode + +00:13:22.920 --> 00:13:26.039 +engine that runs the bytecode. So that's already done. And + +00:13:26.040 --> 00:13:28.239 +you can potentially, on top of that, do something like the + +00:13:28.240 --> 00:13:31.999 +data compilation or a JIT. But we have both an + +00:13:32.000 --> 00:13:47.019 +interpreter and a bytecode compiler. + +00:13:47.020 --> 00:13:50.799 +And I'll just break in one more time to say with about five + +00:13:50.800 --> 00:13:56.319 +minutes left in our live time with this Q&A session, which + +00:13:56.320 --> 00:13:58.439 +we're happy to keep going as long as there are questions. + +00:13:58.440 --> 00:14:03.959 +Coming up in five minutes, we'll have a talk on color on the + +00:14:03.960 --> 00:14:09.639 +gen track. And then right here, we'll have the p-search + +00:14:09.640 --> 00:14:09.959 +talk. + +00:14:09.960 --> 00:14:20.099 +Thank you. + +NOTE Q: Is it possible to bootstrap with just the bytecode interpreter? + +00:14:20.100 --> 00:14:22.559 +Is it possible to bootstrap with just the bytecode + +00:14:22.560 --> 00:14:25.759 +interpreter? So I'll have to put in a link to one of my blog + +00:14:25.760 --> 00:14:28.519 +posts. So that was my original idea was to say, I don't want to + +00:14:28.520 --> 00:14:31.559 +have an interpreter, a bytecode interpreter and a native + +00:14:31.560 --> 00:14:33.180 +compiler. I want to just have just one. + +00:14:33.181 --> 00:14:36.741 +So I'm only going to have the bytecode. + +00:14:36.742 --> 00:14:37.708 +And so that's what I did initially. + +00:14:37.709 --> 00:14:42.079 +The problem with that is, is that a bunch of the early bootstrap + +00:14:42.080 --> 00:14:45.117 +Emacs code is written with the assumption + +00:14:45.118 --> 00:14:47.278 +that it's going to be interpreted. + +00:14:47.279 --> 00:14:49.019 +This is especially true with macros, + +00:14:49.020 --> 00:14:50.821 +where you'll have a function defined, + +00:14:50.822 --> 00:14:52.642 +you'll evaluate part of the function. + +00:14:52.643 --> 00:14:55.599 +The other half of the function has macros in it + +00:14:55.600 --> 00:14:59.719 +that are not defined yet, but it doesn't matter because they + +00:14:59.720 --> 00:15:02.399 +don't get used. But with the bytecode interpreter, it + +00:15:02.400 --> 00:15:04.639 +expands all macros when it gets the function definition. + +00:15:04.640 --> 00:15:08.799 +And so those weren't macros when the function was expanded, + +00:15:08.800 --> 00:15:12.359 +and therefore they got instantiated as functions, but + +00:15:12.360 --> 00:15:15.759 +they're not functions, they're macros. And so I initially + +00:15:15.760 --> 00:15:18.999 +spent a bunch of time trying to work around this, trying to + +00:15:19.000 --> 00:15:21.599 +move code around, work stuff around, refactor the code to + +00:15:21.600 --> 00:15:24.759 +try and get it to work with only bytecode interpreter. And + +00:15:24.760 --> 00:15:27.039 +eventually I just gave up. I said, you know what, I'm just + +00:15:27.040 --> 00:15:30.039 +going to write an actual interpreter to handle this because + +00:15:30.040 --> 00:15:33.799 +trying to handle all these lazy macros is too much work. And + +00:15:33.800 --> 00:15:35.759 +everything in the bootstrap is built with the assumption + +00:15:35.760 --> 00:15:37.799 +that you have lazy macro expansion. + +00:15:37.800 --> 00:15:45.159 +I'm guessing the Emacs bytecode interpreter isn't + +00:15:45.160 --> 00:15:45.959 +complete. + +00:15:45.960 --> 00:15:52.279 +So it's mostly complete. There's a handful of opcodes that + +00:15:52.280 --> 00:15:55.239 +aren't implemented that are pretty easy to add that I + +00:15:55.240 --> 00:15:57.879 +haven't run into. And there's some of them that are + +00:15:57.880 --> 00:16:00.119 +deprecated that aren't implemented, but it's essentially + +00:16:00.120 --> 00:16:00.479 +complete. + +00:16:00.480 --> 00:16:11.999 +We also provide a bytecode JIT compilation via libgcc the + +00:16:12.000 --> 00:16:17.344 +way Emacs currently does it. Eventually I would like to... + +00:16:17.345 --> 00:16:22.919 +I'm more inclined to have a proper runtime JIT than an + +00:16:22.920 --> 00:16:27.399 +ahead-of-time compiler like libgcc, like the current + +00:16:27.400 --> 00:16:29.919 +Emacs native compilation, because it allows you to take + +00:16:29.920 --> 00:16:34.559 +type information and actually apply that to the code, which + +00:16:34.560 --> 00:17:03.959 +can let you do more aggressive optimizations to it. + +NOTE What would it take to bootstrap Guile in Rune? + +00:17:03.960 --> 00:17:06.319 +He said, we may either get a new Emacs with an ancient C core + +00:17:06.320 --> 00:17:09.039 +with a modern Lisp, or an Emacs with modern core, but stuck + +00:17:09.040 --> 00:17:11.879 +with ancient Elisp. So there was another project I was + +00:17:11.880 --> 00:17:16.639 +talking to, one of the Guile implementations, about how we + +00:17:16.640 --> 00:17:19.119 +could potentially, he was like, what would it take to + +00:17:19.120 --> 00:17:24.479 +bootstrap Guile in Rune, where you have both, you could have + +00:17:24.480 --> 00:17:27.399 +Elisp and Guile running inside this project. And so we've + +00:17:27.400 --> 00:17:28.999 +started that discussion, which I think would be, which + +00:17:29.000 --> 00:17:33.999 +would be interesting. But it's tricky too, because + +00:17:34.000 --> 00:17:36.199 +fundamentally Elisp and Guile are two different + +00:17:36.200 --> 00:17:38.119 +languages. They have different semantics. They have + +00:17:38.120 --> 00:17:39.879 +different ways of handling things. You've really got to + +00:17:39.880 --> 00:17:42.479 +consider both of those when you're trying to make them work + +00:17:42.480 --> 00:17:42.799 +together. + +00:17:42.800 --> 00:17:57.319 +How would you do the native module system? What would be + +00:17:57.320 --> 00:17:59.799 +different? We can do the same thing. We have an FFI. So I + +00:17:59.800 --> 00:18:03.839 +haven't looked into it a ton, but I feel like it could be + +00:18:03.840 --> 00:18:06.359 +similar. And I'm actually interested, there's a couple + +00:18:06.360 --> 00:18:12.759 +projects on GitHub right now to have an FFI written in Elisp. + +00:18:12.760 --> 00:18:17.239 +So you don't even need to create a separate C or Rust module, + +00:18:17.240 --> 00:18:21.679 +because you can actually write native modules in Rust or C. + +00:18:21.680 --> 00:18:25.559 +And so you can just have direct bindings to a C FFI written in + +00:18:25.560 --> 00:18:27.799 +Elisp. You don't need any C code inside there. And I think + +00:18:27.800 --> 00:18:33.699 +that would be an interesting approach to look at as well. + +00:18:33.700 --> 00:18:35.839 +Oh, Ramin. Yeah, that's right. We were talking about that, + +00:18:35.840 --> 00:18:41.539 +about bootstrapping Scheme. + +00:18:41.540 --> 00:18:45.519 +And at this point, we have broken away from, uh, from this + +00:18:45.520 --> 00:18:47.399 +talk, but we're continuing to record and this will all be + +00:18:47.400 --> 00:18:50.439 +published. I'd say, go ahead and keep going as long as you'd + +00:18:50.440 --> 00:18:54.959 +like in here. And, um, thanks once again for the awesome + +00:18:54.960 --> 00:18:58.639 +discussion. Thank you so much. So I'll just pay attention to + +00:18:58.640 --> 00:19:02.919 +the ether pad and the chat and see. + +00:19:02.920 --> 00:19:05.919 +That sounds good. I'll keep an eye on IRC. And if there are + +00:19:05.920 --> 00:19:08.559 +more questions here, I'll bounce people toward the ether + +00:19:08.560 --> 00:19:12.760 +pad or this, uh, chat room. All right, thank you. |