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.
