All right. Hey, thanks for bearing with us there. We had a
couple of bumps in the road, a cross between a couple of
different versions of our program that we deliver here,
different ways that we bring this stream together between
the recorded content that that speakers are putting
together in advance in the live content, such as what you're
seeing right here. So thanks go to Sacha and Leo, and
everybody behind the stages gluing it all together. And
we're back here now, and I'm speaking with Robin, who us
ready to take on some of your questions and address some of
the comments over here on the etherpad. If you want to jump in
there, there's links in the chat. And thanks so much, Robin,
for your talk. And it's also been a pleasure chatting with
you just a little bit over the last couple of months on IRC.
Yeah, absolutely. Great meeting you.
All right. All right, everyone. I think I am streaming now.
So let's look at it. Let's see. I see the IRC scrolling. So
let's see where that's going. Yes, the Common Lisp is what I
thought would piss people off. And because it's not part of
either community, but I think it would be a good compromise
for building a Lisp into a language that's more suitable for
building large systems like the kind that we are building in
Emacs today. I also left out an important part of the talk,
which is part of the motivation for transitioning from C to
Lisp. And that's the performance characteristics
fundamentally change when you get a modern and high
performance Lisp system involved. it starts getting less
practical to just call out to C to speed up every operation.
Among other things, you lose the ability to use more
advanced control structures, like the limited
continuations. And you also have to pay the overhead of
calling out to our foreign function. So it gets to be an
increasingly better deal to optimize your list
implementation and provide ways for building faster list
programs, such as type annotations, once you've gotten
over a certain threshold of performance.
I'm going to look at the pad. Here we go. The first question is
about fibers and whether they help with making Elisp
concurrent in terms of its data structures. Yes, that's
absolutely correct. Fibers by themselves do not provide
thread safety for any of the existing Emacs data
structures. What they are useful for is building things
that don't use Emacs data structures, say a network client
that reads input from a stream or in scheme, a port or a stream
instead of a buffer. And we can also take a look at options for
making more Emacs features concurrency safe or thread
safe. For example, we could introduce the idea of a thread
local buffer that didn't require locks for sharing between
different threads. And I'm not sure how that would develop,
but I'm sure the Emacs maintainers already have some ideas
in this direction. Fibers will basically provide a
high-performance system that you can use apart from
ordinary Emacs-less constructs.
Let's see. We have another question. Emacs is roughly 25% C.
How much of Guile is in C?
Well, part of my point about C is not so much that there, well,
obviously, I phrased it a little provocatively, but the
problem is not so much that there is C, but that there is so
much C involved in every single layer of the application.
So, for example, we're limited in our ability to use tools
like limit continuations, which can be used to express
buffer local variable binding in a few dozen lines, because
Emacs has so much calling back and forth between guile and C,
due to so much basic functionality being in primitive C
subroutines. So that's one issue apart from the question of
how much is in a particular language. To answer the question
about Guile, Guile has about 165,000 lines of scheme code
and about 160,000 lines of C code, so it's about half and
half. And that shouldn't really be surprising given that it
is actually focused on low-level things like building a
high-performance bytecode compiler, and a just-in-time
compiler, and so on, as well as providing its own fairly
rich, but still far less complete than Emacs's standard
library, in terms of Ice9 and other system libraries
shipped with Guile. The next question is on a Common Lisp
implementation for Guile, and whether work on it is
underway. In fact, work on it is already underway. I've been
working on it on and off in my spare time for a couple of years
now. I've gotten, I think, a couple of chapters of the
hyperspectin, if you want to measure it that way. But I've
been focusing my work more on research and on what we need to
do to have a LISP environment, a polyglot LISP environment,
wherein the features of Common Lisp and Scheme and Emacs
Lisp can all work easily and ergonomically together. So
this involves things like the question of Lisps having
Lisp1s versus Lisp2s. That is, a Lisp1-like scheme has one
namespace, like every variable is a single name that can
refer to one value, whereas in Lisp2s like EmacsLisp,
symbols can have different definitions as functions and as
variables, as well as other namespaces like property
lists. So Kent Pittman has some interesting thoughts on
this that I've been looking into. Another issue is the
interaction between package and module systems. So I don't
have really anything ready to publish just yet on this, but I
have been looking into the background issues of
integrating this into Guile in a useful way.
And let's see, one other thing I was going to mention.
Okay, I've lost it. But yeah, there is some work already. And
if people are interested in moving Emacs in this direction,
then we'll certainly start working on it in earnest.
Another question, did switching from Guile 2 to 3 give any
performance benefits? Well, honestly, we're not really
benchmarking stuff here because Guile Emacs has so much
overhead from structuring the compiler to closely conform
to Emacs in terms of like even things as simple as metadata
layout for variable information.
So I haven't actually noticed a perceptual change. I would
guess based on the Gabriel benchmark results that is
benefited from what somewhat from Gal 3's performance
improvements but for Emacs I just don't know yet and working
on the compiler's code generation and lowering the
overhead is going to be the thing that provides the most
return for improving that aspect of Gal Emacs.
Let's see, I see SICL mentioned here, as well as SPCL. And it
could certainly help with the implementation of
Commonwealth and Guile, because a lot of the basic stuff is
just providing a new interface to some bit of
functionality. Like the sequence library, it's mostly
stuff that we already have through SR5 and so on. The
difficult, well, not the difficult but the time consuming
parts are going to be all the little DSL sitcom on this path
packed up inside it like pretty printing format loop and so
on. It's for those high-level features that I think we could
potentially share code with other Common Lisp
implementations. And Common Lisp implementations do tend
to be permissively licensed, SPCL's public domain, for
example, so there's no barrier to sharing code with them.
There's another question about whether the Emacs
maintainers are interested in switching to Guile as the
engine for Emacs Lisp. I can't speak for the current
maintainers. I can say that people have talked to previous
Emacs maintainers about the whole idea, and their attitude
was generally cautiously optimistic. As in, it's not
something they, it's somewhat political, they didn't want
to get into it, but they didn't think that it was a bad idea,
and they wanted to know more about how it might evolve in the
future. I can comment that Eli Zaretsky, who I believe is the
current Emacs maintainer, is very concerned about
cross-platform compatibility. And so if I can guess at his
priorities correctly, I think that that's something that
we'll have to make sure is rock solid before we propose any
kind of upstreaming of Gala Emacs. but in general
maintainers have been cautious but curious. So I just
wanted to break in and note at this point that as lives I
didn't sorry I couldn't do so more gracefully while we were
still on stream but I wanted to let you know that just as of 10
seconds ago or so we've had to cut away into our next talk but
we can keep going here as long as we like. Okay, let's wrap up.
There's only a couple questions left on the pad, so I'll
answer those, and then I'll be available on IRC. So, the next
question is whether Guile Emacs will be able to collaborate
with projects like Gypsum and
the native compilation projects or the pre-scheme
efforts. Oh, yes, that is one of the things I forgot to bring
up in my talk. So, first of all, Gypsum is approaching a
similar idea from a different direction. And we clearly
have a different focus. My focus is on improving Emacs Lisp
and making Emacs itself better by integrating Guile Elisp
and Emacs, rather than replacing eLisp or deprecating it in
any way. But given gypsum's requirements, I do think that we
could share a lot of code required for emulating basic Emacs
functionality. And this could even become interesting if
we get to the point of rewriting parts of Emacs in Lisp. With
respect to the native compilation effort, I'm familiar
with it. I'm not that impressed with the results of it. It's a
very impressive effort, but as far as I can tell, it's
accelerating a bytecode interpreter that just simply has
an out-of-date design, to be quite blunt. It's possible
that Emacs's JIT has ideas that Guile should adopt, like
perhaps libgccjit might perhaps be better than GNU
Lightning, which is a relatively simple JIT that Guile
uses.
But it doesn't have to have a direct relationship to Guile
Emacs. And as far as pre-scheme goes, I have been watching
Flat Watson's work on pre-scheme with great interest
because Scheme 48 used to be my favorite implementation.
And I do think that it could be, it's a tool that we should look
at when we're thinking about moving functionality into
Lisp and could certainly make it easier to upstream some of
the work we may end up doing.
All right, do we have more questions?
There's a question about SICL and SBCL. I think I answered
that earlier. It should help us implement Common Lisp when
it comes to high-level features and the various large
subcomponents of Common Lisp. Another important factor is
that Guile already has decent support for the Common Lisp
object system. Without that, it would be far more
difficult. But I do expect that we can share code with other
Common Lisp implementations. I've personally rated
Common Lisp compiler code when working on Guile Hoot, for
example. So there are definitely places where they can
contribute.
Regarding the Hoot project and its relationship to
Galimax, it's a purely speculative thing. First of all,
Hoot is only tested on Scheme-to-WebAssembly
compilations. I've heard some suggestions that some uses
of Tree.io may not be compatible with the Hoot compiler. I'm
not sure if that's the case or not.
But it is a complete enough project that if Emacs is, say, 90%
Lisp, there's only a few thousand lines of C code to
implement, then it would be entirely practical to compile
Emacs WebAssembly, as long as we had a back end, like one
based on the browser's document object model, or some sort
of graphical interface through WASI. And that may have some
interesting applications for portability to unusual
platforms. It may even bring performance advantages in
cases where the WebAssembly implementation is connected
to a tracing just-in-time compiler, because that may be
more appropriate to the high level of dynamism the Emacs
list has than the kind of simple template JITs that both
Emacs and Guile are using.
What a fascinating point. Just to break into active
listening a little so this doesn't, to you, feel like you're
talking to yourself. I can see from chat and the questions
still coming in, you know, comments. You know, it isn't, but
I just want you to be able to hear and feel that. Yeah, great,
great point there. All right. Thank you. And yes, if there
are more questions, keep throwing them at me. I should
probably also mention I will have to jump out myself, but the
recording will automatically end when we all jump out or
just drop a note anywhere, ping me, whatever. And I'll come
along and shut off the recording and we'll trim it up before
we publish it. I'm looking forward to reading through
anything I do miss. Thank you. Sounds good.
All right, I'm not seeing changes in the etherpad. So I'm
going to close this in maybe 30 seconds if there are no more
additions. Thanks, everyone, for the interesting and very
pointed questions on some of the most significant areas. I
appreciate everyone's feedback. I'm glad this provoked so
much curiosity in people.
Thank you, janneke.
All right, I think we are done with the Q&A session, so I'm
going to close this BBB and we can continue with the rest of
EmacsConf.
You are currently the only person in this conference.