Back to the talks Previous by track: Bookclub tapas Next by track: Juicemacs: exploring speculative JIT compilation for ELisp in Java Track: Development

One year progress update Schemacs (formerly Gypsum)

Ramin Honary (he/him) - Pronunciation: "Rah-mean" (hard-H) "Ho-na-ree", Mastodon (preferred): ; blog: https://tilde.town/~ramin_hal9001; Codeberg: https://codeberg.org/ramin_hal9001/schemacs - SourceHut: https://sr.ht/~ramin_hal9001

Format: 24-min talk ; Q&A: BigBlueButton conference room Etherpad: https://pad.emacsconf.org/2025-schemacs
Etherpad: https://pad.emacsconf.org/2025-schemacs
Status: TO_REVIEW_QA

Talk

02:07.200 The scope of the project 04:24.760 Difference with Robin Templeton's project (Guile-Emacs) 05:49.720 Progress made since last year 07:28.040 Portable React-like GUI 09:06.040 Demo 11:48.700 Additional changes 14:12.020 Other Scheme implementations 17:06.200 GUI framework 21:51.520 Wrapping up

Duration: 23:14 minutes

Q&A

Duration: 31:11 minutes

Description

During EmacsConf 2024 last year I presented my work on a clone of GNU Emacs written in Scheme which also clones the Emacs Lisp programming language. In this talk, I will briefly present an overview of the project similar to the talk I gave last year, and then discuss the progress that I have made on this project in the past year.

To quote the description from the presentation I gave last year:

Unlike other editors which only clone the Emacs keybindings (Edwin, Jed, jEdit, Jove, Lem, MG, Yi, Zile), I hope my Emacs clone will also fully clone the Emacs Lisp programming language well enough that many of the packages in ELPA, Non-GNU ELPA, and perhaps even MELPA, can be used in [Schemacs, formerly "Gypsum"] without any modification. I would also like to talk a little bit about how I am implementing it (the software architecture), and invite others to contribute.

I think my project is of interest to many Emacs users because, firstly, I have personally spoken with a relatively large number of people who have expressed interest in making Emacs programmable in Scheme. Secondly, there is a good amount of prior art for Scheme implementations of Emacs. There are even builds of Emacs that link to Guile which provides a "scheme-eval" built-in function that translates between Elisp data types and Scheme data types. The Guile compiler itself ships with an Emacs Lisp compiler as well, although it does not provide enough of Emacs's built-in functions to be of much use.

The progress I have made so far:

Ported all Guile-specific parts of the Emacs Lisp interpreter to fully standards-compliant R7RS Scheme code. The interpreter now runs on a few different Scheme implementations, not just Guile. The GUI remains Guile-only for now.
Implemented a new R7RS-compliant lexer and parser which constructs an Abstract Syntax Tree (AST) data structure, making it easier to find the source of errors and produce informative back traces.
Implemented enough of the Emacs Lisp interpreter to be able to load the "subr.el" source file, this defines what you might call the "core" of the Emacs Lisp language, including macros such as "defun" and "lambda."

My primary goal continues to be to make it as easy as possible for other people to contribute to this project. Pretty soon it should be possible to run the Emacs Regression Test suite (ERT) in the cloned Emacs Lisp interpreter. Once this is done, we can run the same test code used during the building and testing GNU Emacs to test Schemacs. Hopefilly then, anyone will be able to select a failing test, write code to make the test pass, and submit a patch.

About the speaker:

I am Ramin Honary, I am have been professional software engineer for 17 years and I have always had a passion for functional programming languages, especially Haskell and the Lisp family of languages.

Transcript

Hi, EmacsConf 2025. My name is Ramin Honary, and I'd like to talk to you today about my project called Schemacs which I presented last year. Back then it was called "Gypsum" and the name has since changed. So my name is Ramin Honary. I'm an Emacs enthusiast, have been since 2017 or so. I'm a full stack software developer. I love Haskell, Scheme, anything functional programming related, and of course Emacs. I started learning Scheme about three years ago, and this is my third time presenting at EmacsConf. So the Schemacs project that I'm talking to, I'm talking about to you today, was originally called "Gypsum". The reason I did not call it "Schemacs" was that the name "Schemacs" was taken on GitHub. But in the past year, I was able to get the permission of the author of GitHub's Schemacs project to name my project the same thing, even though it's a very similar project. So I changed the name. Let me see if I can quickly show the screen. So yeah, I have archived the old project. It's still there, but there's an explanation in the readme file and a screen grab of the conversation I had with the original author of GitHub Schemacs. My Schemacs is not on GitHub at all. It's only on Codeberg. So please don't get confused. But yes, I received permission to change the name and so I did. And I would like to give a quick shout-out to user "Tusharhero" for helping me with that. This person really helped make that name change happen. So back to the slides.

[00:02:07.200] The scope of the project

And so now I'd like to clarify the scope of the project. I don't think I quite made it clear well enough last year, but... Although I'm definitely cloning the Emacs Lisp programming language, the actual scope of the Schemacs project is to make an Emacs-like app platform for Scheme. I don't consider Emacs to be a text editor. I consider Emacs to be a Lisp app platform. So it's similar to something like the World Wide Web, or Microsoft's .NET app platform, or Java. These are all examples of app platforms. I would like Schemacs to make it easy for not only people to use it for things like editing text or, you know, for using your computer through a command line or manipulating your Git repository. I'd also like you to be able to create simple GUIs or TUIs using Scheme. So that's also one of the goals of this project. It will of course have an Emacs-like text editor, and I will clone Emacs Lisp. So hopefully GNU Emacs users will feel comfortable moving over to Schemacs because they'll be able to use your init. You'll be able to use your init.el file. So configuring and scripting Schemacs should be done in Scheme. I'd like to encourage scripting in Scheme and creating new workflows and macros in Scheme. It will support Emacs Lisp depending on how much of the Emacs Lisp interpreter I can clone. That will be supported but not encouraged. But you should still be able to run your init.el. And I would like it to be good enough, this Emacs Lisp interpreter should be good enough to run packages from ELPA. Although it will probably be some time before it will be able to run something as large as Org Mode or Magit.

[00:04:24.760] Difference with Robin Templeton's project (Guile-Emacs)

It is slightly different from the Guile-Emacs project. This is the work of Robin Templeton who presented last year. Guile-Emacs links the Guile runtime into the Emacs executable. It's not a Scheme application. Emacs, the core of Emacs is written in C. Guile, the core of Guile is written in C. What Robin Templeton has done is, at the C level, linked "libguile.so" into Emacs and then provided a programming layer where you can call the Scheme interpreter from Emacs Lisp so that you can run Scheme programs from within Emacs without having to launch a separate process and communicate over a channel such as a socket. You won't need "SLIME" or anything. The Guile interpreter is just right there inside of Emacs. But my project is not like this at all. Schemacs is written completely from the ground up in R7RS-compliant Scheme. And because it's R7RS-compliant, it's not bound to any one particular Scheme implementation, although Guile is the reference implementation. One goal of this project is to be able to run Schemacs on any R7RS-compliant Scheme implementation.

[00:05:49.720] Progress made since last year

The work that I've done this past year mostly is internal. There's not much that you can see on the surface. But the most... One of the most important things that I did was I rewrote the parser in R7RS Scheme, so it no longer depends on the Guile regular expressions library. The parser now also provides source locations, so if an error occurs in Emacs Lisp, there will be a stack trace and it will show you where in the source code the error occured. This was not possible last year. And because it no longer depends on Guile, I can make it work on multiple Scheme implementations. So far, I've been able to get it to run on the Chibi Scheme interpreter and the Gauche Scheme interpreter, as well as Guile, which is the reference implementation. For a short time, it did work also on Chez Scheme, the Chez Scheme compiler, using Gwen Weinholt's "Akku," which is a program that translates R7RS Scheme to R6RS Scheme. And with that translation, because Chez Scheme is pretty strictly an R6RS compiler, the translation allows you to run R7RS programs. But due to some change, I'm not sure where, it may have been changed in the Schemacs source code, or it may have been a change to Akku, but it no longer builds on Chez. It did at one point. I'd like to try to fix that.

[00:07:28.040] Portable React-like GUI

The second most important thing that I've worked on is a portable React-like GUI. And so React, for anyone who has done web programming, is a very popular framework for programming web applications. And I've provided something very similar to that in Scheme now. So it works. I have constructed a DOM data structure in Scheme. It's just an ordinary Scheme data structure. It works like the web's "Document Object Model" or the "DOM" data structure. And then this Scheme DOM data structure can be rendered using any GUI framework that is convenient for the Scheme implementation that you're targeting. And you should be able to implement also rendering to a CLI as well. The current reference implementation is using a framework called Guile-GI. This is the "GObject Introspection" framework. It's a very simple GObject Introspection framework for Guile, and it binds to GTK3 on Linux. There's a similar framework called G-Golf which I'd like to begin using as well, also for Guile. G-Golf seems to be a bit more well-maintained, a bit... It has better features. G-Golf may be a better rendering backend for the reference implementation, but I would like to provide both.

[00:09:06.040] Demo

I will give a demo of this now. Unfortunately not a whole lot to see compared to last year. First thing I'd like to show is that I now have a Makefile. You can look inside this Makefile and if you're able to read a Makefile, you can see that I have several targets now available. You can build Schemacs for Guile, you can build Schemacs for Gambit, or Stklos, or Chicken, or Chez, although none of these (except for Guile) currently works. These targets will actually build the source code, but then you would have to load it into the REPL separately. There are targets for launching a Gauche REPL and a Chibi REPL. You can also run the Emacs Lisp tests in Gauche and Chibi. You can also start a Guile REPL through this Makefile. So I will do that right now in the shell. (...make the text larger...there we go...) OK, so we have this directory of the source code. Let's just begin by running "guile.sh". This will launch a REPL and you can load "main-guile". This will launch the GUI. This is the basic proof of concept GUI that uses Guile-GI. So it may be hard to see. I cannot change the size of the text yet. I've implemented the M-: feature where you can eval in a minibuffer some Scheme code. (string-append "hello" ...) It outputs the result in the buffer. This is basically the "*Messages*" buffer. And that's all the more that I have. This is the same state it was in last year. It hasn't changed a whole lot since back then.

[00:11:48.700] Additional changes

But I have made additional changes. So first of all, you can run (let me just go back into the Guile)... you can run the Emacs Lisp interpreter tests, so "elisp-tests". As you can see, it gives you a stack trace. So this is an error that I've been able to reproduce. I know exactly what the cause of this error is. It is not finding a variable because the closure is not correctly capturing its environment. So there should be a variable in the closure, but that variable has not been captured and so it is causing an error. It is currently loading "byte-run.el". Let me show you what code that is here. So I've copied into the source repository for Schemacs some of the Elisp code from GNU Emacs. So I have this "subr.el". This declares most of the core of Emacs Lisp that's not written in C. There's also "byte-run.el". Schemacs Emacs Lisp can now evaluate this. This is where functions like "defun" are defined, and "defmacro". So as you can see, defun itself is a defmacro defined right here. It's written in Emacs Lisp itself, defined in terms of defalias. So I can evaluate "byte-run", I can evaluate "macroexp", and the failure occurs somewhere in "subr.el". Although if you look at the stack trace, it doesn't provide all the necessary information. So it appears to be happening in byte-run.el. Really, it's an error that's occurring inside of a macro, and the macro call site is somewhere in subr.el. Anyway, take note of this stack trace. This was run from within Guile.

[00:14:12.020] Other Scheme implementations

Now what I've done this past year is make it work on other Scheme implementations. Use "make" to launch a Gauche REPL. Now I'm inside of Gauche. This is the command that you would use to launch a Gauche REPL. And I can load the same program (load "elisp-tests.scm"). You get the exact same result as Guile. So we have two different Scheme implementations producing the same result. Let's try "make" a Chibi REPL. This is Chibi Scheme. And you can (load "elisp-tests.scm"). Chibi is a bit slower, but you get the exact same result. So we have three different Scheme implementations all running Emacs Lisp, and all producing the same result. I think that's... I'm fairly proud of that accomplishment. I was able to get the code written to the point where it actually runs on multiple implementations. You can also try making it for other Scheme compilers like "schemacs-mitscheme" for example, but this will fail. You can try building it for "schemacs-chez", Let's try Chez... there we go. And it will use Akku, and it will fetch the necessary dependencies. But it fails, and I haven't been able to debug that quite yet. Stklos fails for a similar reason. Gambit... Chicken still doesn't build all the way yet. The Makefile at least has places for it. If anyone can help me out and get Schemacs to compile on these other Scheme implementations, I'd appreciate it. I can probably figure it out myself, but that will take more time. And let me just show you quickly the test program. Basically this is the Emacs Lisp test program that I was just running, and it produces an error. All it does is it loads these files here in this order, and it fails right around here. So it's able to load these two. And yeah, that's what I've accomplished on the Emacs Lisp side of things.

[00:17:06.200] GUI framework

The next thing I want to show you is the GUI framework that I've written, which I'm fairly proud of so far. So this is the GUI framework (oops, I better launch it again, OK...) and let me show you the tests. So here in the tests, you can start to see some examples of how you use it. So here is a "counter" test, and this is kind of like the "hello world" of reactive programming frameworks, where you have a state variable, sometimes called an "observable." I'm calling it "number", and it uses "=" to check if the state has updated. If an update occurs and the new value is different from the old value according to the "=" function, then trigger a state update in the GUI as well. Initialize to 0, bound to "number". I have a "button" function which creates a simple button. It takes a label and an action. Right here you see the "div" command. This is what creates a "div". Using the properties, I describe that this div is a push-button and the "on-button-push" is an action. The action is to update the variable "number" using whatever function or lambda was provided to it. And then the content that you see on screen, that you will see on screen when it runs, is here. You create a "div-pack cut-vertical". You declare two buttons and then you declare this "use-vars" which will take the content of this variable here, this observable, and place it into the GUI next to the buttons here. So what you will see on screen is a "plus" button which increments, here is the "increment" function, a "minus" button which decrements, and then the content of the variable that is being incremented and decremented. The advantage of these reactive frameworks is that with very few lines of code you can create fairly complex interfaces. The less code you have to write, the fewer chances you have to make mistakes. So let's just run this program. This was the "counter-test." And that is the debug window. Here's the "counter." I'm sorry it's not much larger than this. But here's the "plus" button, the "minus" button, and here's the "number", 0. And I can increment or decrement as much as I like. So yeah, that's kind of the hello world of reactive programming. (I'll reboot the REPL...) The next thing I want to show you is this layout test. And I'll just run the test first. So here we have basically a tiling window manager kind of thing, where you can resize the tiles and then by clicking on these buttons here, you can change the layout. So you can do two on the right, two up above, or three up above. So, yeah. Those tiling windows, as you can see, once I work this branch into the main branch of Schemacs, I can use that to implement the split window functionality for Schemacs, the editor. So here's what this split... Here's the layout test that you just saw. Let me make it a bit smaller so that it all fits on one screen. So basically we have the "button" command again, and then these are the button actions which basically just changes the layout, and then I have the layout. So this layout is a "div." The first div just places three buttons in a row. The next layout is a div within a div. So we have one div which places the button called "two right" buttons, and the div above it, which places the "three in a row" button or the "two above" buttons. And here's the next... So there's three different layouts, and clicking on one of their associated buttons will just change the layout. As you can see, very little code to create a somewhat complex user interface. That's the advantage of using reactive or declarative UI programming paradigms. So yeah, this has not been merged into Schemacs at the time of this recording, but will be soon hopefully.

[00:21:51.520] Wrapping up

So yeah, I think I've already gone on for 20 minutes. So I guess I'll just end my presentation here. I have lots more to talk about. I guess I will say one last thing before I go: that I would very much like for others to try and contribute to this project. I will do my best to try and help teach anybody or work with anybody, especially even if you don't have much experience with Scheme. I'd like to help everybody try to contribute. Basically I want to get this proof of concept working. I want to get a stable user interface up and running, and then we can start working on improving the Emacs Lisp interpreter all together. There are close to 1,400 built-in functions which need to be implemented. We don't need to get all of them in order to be able to run probably most of ELPA, but as much as possible. We would like to clone Emacs Lisp and I need help. So get a hold of me. My project is on Codeberg. Well, (oh, I can't show this here), but I will end it there. Thank you for listening.

Captioner: sachac

Q&A transcript (unedited)

[oops, forgot to start] object protocol has a scheme implementation. Does this mean schemacs will be meta object changeable in practice? So I don't actually need the meta object protocol so far. In the reference implementation for Guile, Guile has its own object-oriented system called Goops. I'm sorry, I'm hearing a delay. Anyway, I'm going to turn off my stream quick. There we go. So, um. Yes, uh, I, I don't I wasn't aware of the, um. the meta-object protocol that you have mentioned here, but I will look into it. I know that there isn't really a standard meta-object protocol for Scheme. That was an issue for me because I'm trying to make this cross-platform, and so I've done all of my work so far without a meta-object protocol because that's the easiest way to make it work on multiple Scheme implementations. But if there is a nice portable one that works on many implementations, I would use that, yes. It's just that so far it hasn't been necessary. I've been doing mostly functional reactive programming and React.js-like framework. I've created that for the GUI front end. And that's all the more I've needed so far. So, yeah. Oh, yeah, please, next question. Sure. So how will the GUI display code be R7RS compliant? As far as I know, there's no DL open in R7RS. That's right. Yeah, R7RS small is extremely small and does not have any features at all. But it does provide a conv expand macro. And this allows you to load in different code depending on which scheme implementation you're using. So basically, I'll have to write a different back end for each scheme implementation. And I think that's really the only way is possible at all, because there's no standardization. So essentially, the libraries that I've written for schemacs will become kind of a platform-independent way of writing GUIs for Scheme. It's just a matter of, will your Scheme implementation support the Schemacs GUI protocol? So I've kind of written my own protocol, and it's entirely R7 RSML compliant. It's all done with record, what are they called, record types. Do you think some of the Schemacs could be extracted into SFRIs since you've made it portable between scheme implementations? Yes, I would definitely like to do that. Probably first thing I'll do is start splitting up and publishing independent libraries on the Aku package manager. This is a kind of a package manager ecosystem for Scheme, and in particular R7RS Scheme. And it's also mirrored on the other package manager, Snowfort, just by the way. But yeah, and then I might be also, I've considered creating a SRFI for the lens library, which is based on the Haskell lens library. I don't think that exists yet in Scheme, so I thought that might make a good SRFI. Is there a recommended Scheme implementation? Guile is the reference implementation. It's the only one that works with GUI, but as I demonstrated in my presentation, the Emacs Lisp interpreter works on multiple schemes so far, and I've had trouble with some of the scheme compilers. But yeah, I would recommend Guile. But how would schemacs deal with Emacs's re-display architecture will be having its own display architecture? And if so, how will you handle things like overlays and images? Yeah, definitely. That's to be determined. So basically, the scheme way of doing things So, I've created this React-like programming framework. It's like ReactJS or Vue.js. That is just the API of how you write GUI code in Scheme. And each Scheme implementation will have its own GUI backend, which implements that Protocol. And so when it comes time to link the Emacs Lisp built-in functions that do these things like overlays and so on, we're going to have to come up with some way of modeling that using the scheme framework that I've designed. And I may have to make alterations specifically to support Emacs Lisp. I don't know yet. I haven't got that far. You were saying that you would like to get the most out of the 1300 and something Emacs packages that exist. Are there technical blockers to doing them all or just a problem of getting enough people to jump into it? Yeah, it's just a matter of implementing enough of the Emacs built-in functions. Right now, there's kind of a big bug. I mentioned this also in the presentation. The stacks trace that you saw during my presentation, that is the biggest bug right now that's preventing me from running most other code. And I don't think other people will be able to contribute to the code base until I get that bug fixed, because it doesn't capture closures correctly. it doesn't behave like Emacs Lisp does, and that's the big problem. So once I get that worked out, then it's just a matter of implementing enough of the EmacsLisp built-in functions, these are the functions that are mostly implemented in C, implementing those in Scheme. And that, yeah, that's the thing that I'm going to need a lot of help with because there's quite a few of those APIs. But I imagine, I have no idea, no way of knowing, but I imagine we don't need 100% of them in order to run most of Elpa. We probably can get some of the important large Elpa packages like Magit and Org mode with just enough of the Emacs Lisp built-in functions to handle that. But we won't really know until we've tried. So yeah, I'll try to get this bug fixed right away. That way we can all start working on it together, hopefully. Highly relatable answer there. We'll burn that bridge when we're on it or something. What are your thoughts on chicken scheme? Will that be a good fit? Do you think? I think it will be, um, I, I did show trying to run chicken scheme in my, um, presentation and, uh, I ran up against some kind of issue, which I really don't know how to debug. Um, it's probably something to do with the, uh, pattern matcher. Um, I'm using the pattern matcher, uh, written by Alex shin, which seems to be the most portable. Pattern matcher, uh, for our seven RS scheme. But not all scheme compilers implement, what is it called? The macro, I can't remember what it's called. There's the macro expansion system for R7 RS small. All of these scheme implementations seem to have a slightly different take on how they work. And so that macro expander has been, for pattern matching, has been the biggest difficulty in making this code portable. And so I'm thinking of ways of maybe trying to ditch pattern matching, but that's such a useful feature and it's hard. So I don't know, we'll see if I can, if somebody can help me get it to work on chicken team, I'd really appreciate it. Can this implementation be used by Guile's Emacs Lisp mode? Guile's Emacs list mode. Okay. Yeah, good question. I did mention this last year in my presentation. Emacs list in Guile is totally different from what I've done. That implementation was written about 10 or 15 years ago. I can't remember exactly when. It is quite incomplete. I don't think it even runs most of the macro expanding code. Some of the code that is written for GNU Emacs in Emacs Lisp, where GNU Emacs is initializing itself, it can't even get the first file in that code. It hasn't been touched in 10 or 15 years. Initially, when I first started this project, I was using the parser for Guile's Emacs Lisp implementation, but it didn't give me things like source locations, so I had to rewrite that. And also, it wasn't portable. So yeah, because I want it to be portable, it's necessarily going to be not reliant on anything that's inside of the Guile library, including the Emacs LISP interpreter that's there. Maybe I could replace the Emacs LISP interpreter in Guile if Andy Wingo would be interested. All right. And I see we've got a few people that did jump into the BBB. I'm just going to quickly, oops. quickly try to make my text a little bigger so I can read a question that came here. I wonder if we can do some sort of pragmatic analysis on popular Emacs packages to see what list of functions they tend to depend on while a function calls down to the lower level. Yeah, that would be good. Somebody please do that for me. Awesome. Somebody's raising their hand. Divya. Let's see. Yeah, can you hear me? Yes, I can. Yeah, go ahead. Hello, thank you. Yeah, this is really awesome. I use Guile, and I love Guile, and I also love functional programming, so this is really nice that you took the declarative approach. One thing that I'm interested in is, are you also considering Racket in the scheme group? Because I know a lot of people do not consider Racket as a sort of scheme thing, because it grew out of it. Do you think you'll take something from Racket? Because I think Racket has a lot of good ideas that can be used. Yeah, I briefly looked at Racket's GUI library, but it's very, very heavily dependent on Racket's macro expander, which is, well, yeah, the macro expander is extremely complex for Racket, and I don't think it's possible to port it to any other scheme, as far as I know. But Racket is based on SheaScheme. And I am making an effort to port my code to Shea's scheme. I mentioned this earlier, but there's the Gwen Weinholdt Aku system, which allows you to translate R7RS to R6RS. And since Shea is an R6RS compiler, I did at one point get the Emacs Lisp interpreter to compile for Shea, although I think There's been a change either to Aku or somewhere in my own code base. It doesn't build anymore, and I'm not sure why. But I would also very much like to run this on Che. And I guess in that sense, we'll be able to work on Racket as well. There's also one other option. Alexis King has written an R7RS language package for Racket. I have not yet tried. running my package on R7RS for Racket. But that would be something interesting. Yes, I would like to try that. Yeah, it'll be interesting. I do have some experience with chairs. So, uh, if I can find some time, I'll, I'll, I'll certainly like to, I would appreciate. Yes. Yeah. Go ahead. Yeah. Another question I have is, like, what exactly is sort of, like, the, the approach is that you'll 1st want to do the interpreter and then have enough list functions. Uh, getting the max list functions interpreted or interpretable. And then go for GUI or do you want to sort of like go hand in hand is like we have the interpreter working on and we have also the GUI and we sort of use one for the other. Yeah, I consider the two tasks to be parallel. So I'm actually doing the GUI separately. The reason why is because the GUI for Schemacs is really just a clone of the look and feel of Emacs. It's not like an actual clone of the low-level C code that puts everything on screen. And I'm actually not really that interested in the low-level details of how Emacs draws things on screen either. I think it has a lot of historical baggage, and I'm actually trying to move away from that. So that was part of the reason why I started with this React.js or Vue.js-like Reactive GUI framework. So that GUI part is completely separate. And I want to worry about the details of how we make the GUI look and feel similar in Schemacs, similar to GNU Emacs. In Schemacs, using the Emacs programming language, I think that's something that we should worried about after we have enough of the Emacs list implemented. Yeah, that makes sense. There are sort of, I'm a bit worried. So, I don't know if, so one of my presentations is going to be tomorrow. I'm working on something called Emacs Viewer. It's a document viewer in Emacs. And essentially one of the issues that I'm up against is that Emacs's display system is sort of very let's say, not flexible. When trying to analyze where this inflexibility comes from, I don't think it's just the display architecture. I think parts of eLISP itself are connected to the display architecture. The notion of a cell in a buffer, itself is connected tightly to how the re-display architecture works. So I think you'll have to sort of figure out what exactly you can salvage from ELISP without taking the display architecture baggage. That's right. I do anticipate that's going to be fairly challenging. It's all Turing-complete, so I imagine we're probably going to end up creating something like an emulator for the Emacs Lisp display architecture in Scheme that will somehow translate down to the React-like protocol that I've written. But yeah, I don't I haven't that's nice. No, this is this is very exciting. Yeah. Oh Yes, it is. Yeah, I'm glad so like a lot of people have told me that they really Are excited to see this project and this really helps me You know keep focused on this project because a lot of people are very interested. So It's so I'd like to move on to a couple of questions from the past. We're starting to build up a good backlog. Thank you for that. Yeah Next question from the pad I have. Can you tell us more about the show stopping bug? How to squash it? How can people help? OK, well, that one, unfortunately, I think, unless you're really a scheme genius and you can really read my code and immediately understand how it all works, I don't think you'd be able to help. It shouldn't be too difficult for me to fix. So it has to do with how closures work. And a closure is basically an object that can be created with stuff that's on the stack. And this is a feature, I think, that was introduced with Emacs 27. I can't remember exactly, but it's actually a relatively recent feature. It was ever since they introduced lexically scoped variable bindings in Emacs Lisp. And so yeah, the problem is that when you create like a let structure and you could declare a variable in the let. And then you create inside of that a second let structure, and you have a lambda inside of that. And the lambda references or uses a variable that was declared in the outer let binding. That outer let binding is somewhere on the stack. And the lambda you can actually return it as a value. So when you do return that lambda, it has to have a note somewhere inside that says, by the way, I'm using that variable. So you need to capture it and restore it to the stack whenever this lambda is applied, whenever you execute it. And that is where the error is. It's not capturing the stack variable properly. And I think what I'm going to do, I haven't looked into it in detail yet because I've gone back to GUI stuff recently, but what I'm going to do, I think, is just do a static analysis of the code inside of the Lambda and see which symbols are being used, and then just capture all of those and place those into the record type that stores the lambda. That's how I'm going to fix that, I think. I hope anyway that's going to work. You never know with bugs. They're always a little bit tricky. Okay, next question. Are there performance concerns with implementing certain C primitives in PeerScheme? So who is it? The famous computer scientist that said premature optimization is the root of all evil. I think it was the guy who invented the A star algorithm. His name escapes me at the minute. But yeah, I'm not concerned about performance yet, although most of the scheme compilers that I have seen, especially Shea and Gambit have extremely good performance characteristics. And so I think there won't be too much difficulty with performance, even implementing some of the C stuff. And besides, a lot of the GUI stuff is already written in C anyway. I mean, it would be cool if we had a scheme GUI library that painted to a canvas, maybe for a Wayland implementation or something. But I don't know. It's not a concern for me, performance. Okay, there are a few more questions. I do want to mention that the stream has cut away at this point, but we're still recording live. All of this will be put up on the website and so on like that. So, I appreciate all the enthusiastic questions and you're kind of tanking through them all. Me too. I love how many questions I'm getting. This is very encouraging and it really makes me want to keep on working on it. So it's great. I'm so glad to hear that because that's exactly the message I think you should be receiving. This is a fantastic project. Thank you so much. I'll just say so myself. If the project is successful, are you worried about a possible split in the community between Schemacs and GNU Emacs? Oh, I have thought about that. And I really don't know what's going to happen. There seems to be already a huge demand for a scheme-based, a modern scheme-based editor. You know, the Edwin scheme for MIT scheme hasn't been touched since like 1987 or something, maybe 1993 or, but anyway. There seems to be huge demand. And so I guess a lot of people who are currently using GNU Emacs will probably just switch over because they've been wanting something like this for a very long time. And then, I mean, is that going to cause fragmentation? Is it really a big deal, though? I mean, it's all GPL-licensed code. I mean, I think a rising tide raises all the ships at the same time. So, yeah, also, the last thing I want to say about that is I would like to contribute some of what I do in Schemacs back into GNU Emacs, if I can. So, for example, I'm going to be working on like a canvas library where you can have interactive canvases and you know you can actually like draw pictures and put things with the mouse and drag things around. And I was thinking you know if if I can figure out how that works maybe I can write something like that for Emacs or GNU Emacs using the Cairo library, you know, SVG rendering library that they have. So, you know, if I have time, I would like to continue contributing to GNU Emacs as well. I'm sorry, what was the name of the library you mentioned? Oh, Cairo, like Cairo. Oh, Cairo, yeah. Absolutely. I spelled that poorly. The dream of never needing to change to the web browser. Would schemacs bring us closer to that? I hope so. That's also a dream of mine. The part of the reason why I wanted to work, you know, make sure I had a really good workable GUI framework is so that I could, you know, we could write apps like, you know, they have a mastodon client written in Emacs Lisp. that would be so nice to have this, you know, a really nice Mastodon client that was right inside of, you know, our scheme environment where we were doing our text editing and other stuff. I've always wanted something like that, or it would be cool to have just a slightly nicer GUI for Magit. So, yeah, I mean, like, yeah, being able to avoid the web entirely and just be able to like, you know, do social networking and do your GitHub stuff, everything from within Emacs or Schemacs in this case, that's a dream of mine as well. And so I hope that that's where we end up in a couple of years. The sooner the better. Anything, just double checking. Anything specific other than minimalism that made you choose Scheme over Commonwealth? Oh, yeah, it's kind of a philosophical question. So a couple of things. First of all, it was a conversation I had with William Byrd, and he's a guy who makes the Mini Conran framework for Scheme. It was his PhD thesis. He worked with, I'm sorry, I just can't remember his name. He worked at the University of Indiana. Another famous Scheme or Lisp person was there. Friedman, Dan Friedman was his advisor. Yeah, big name in Lisp. Anyway, so I was talking with William Byrd, and I'm a huge Haskell fan, and he told me why he didn't like Haskell at all, and kind of convinced me to try Scheme out. And what I really like about Scheme is, yeah, like you said, the minimalism, but it's more that it is very close to the mathematical framework of lambda calculus. Haskell is probably the most pure lambda calculus that I've ever used, but Scheme is like the simply typed lambda calculus, and That just appeals to me. I think, you know, if you have this tiny, tiny core language from which all of the computing can be defined, I think it's kind of a shame that so far we just haven't explored that space yet. I mean, there's compared to JavaScript or Python, there's very little scheme code out there and it could be doing so much. And I would just like to try and expand the scheme ecosystem and see just what this tiny little language can do. And I think we haven't even seen a fraction of what it can do. That's why I've chosen scheme. Divya, I see you've got a bunch more comments. I think we're just about close to our time here, but if you wanted to jump back in, I'm sorry, I had to cut you off a little before. No, it's fine. No, it's fine. I think I agree with most of what he said. So, yeah, thank you so much. Um, closing thoughts, Ramin. Yeah, I guess everybody, please, if you're interested, keep watching my Mastodon and keep watching my Codeberg. I'm going to try and squash this bug as quickly as I can. I hope early next year, hopefully not much later than February, I'll actually be able to start taking in contributions for some of the Emacs Lisp built-ins in the code base. So, please keep watching. The pace of my development has increased pretty rapidly recently, and I think we're pretty close to getting something that we can all use together. Thank you once again for your amazing talk, for your exceptional work, and for jumping in, doing the live Q&A, rolling with us here as we have yet another We'll See How It Goes conference. It's been just amazing so far, and this talk is no small part of that. Thank you. Oh, thank you so much. Yeah. OK, cool. And thanks for all the questions, everyone.

Questions or comments? Please e-mail emacsconf-org-private@gnu.org

Back to the talks Previous by track: Bookclub tapas Next by track: Juicemacs: exploring speculative JIT compilation for ELisp in Java Track: Development