path: root/2024/captions/emacsconf-2024-guile--beguiling-emacs-guileemacs-relaunched--robin-templeton--answers.vtt

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.