add answers captionsHEADmaster

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.