path: root/2025/captions/emacsconf-2025-schemacs--one-year-progress-update-schemacs-formerly-gypsum--ramin-honary--answers.vtt

WEBVTT

00:00:00.000 --> 00:00:03.839
[oops, forgot to start] object protocol has a scheme implementation.

00:00:03.840 --> 00:00:07.159
Does this mean schemacs will be

00:00:07.160 --> 00:00:11.079
meta object changeable in practice?

00:00:11.080 --> 00:00:16.599
So I don't actually need the meta object protocol so far.

00:00:16.600 --> 00:00:19.279
In the reference implementation for Guile,

00:00:19.280 --> 00:00:27.559
Guile has its own object-oriented system called Goops.

00:00:27.560 --> 00:00:29.239
I'm sorry, I'm hearing a delay.

00:00:29.240 --> 00:00:32.519
Anyway, I'm going to turn off my stream quick. There we go.

00:00:32.520 --> 00:00:39.439
So, um. Yes, uh, I, I don't I wasn't aware of the, um.

00:00:39.440 --> 00:00:43.919
the meta-object protocol that you have mentioned here,

00:00:43.920 --> 00:00:45.959
but I will look into it.

00:00:45.960 --> 00:00:48.719
I know that there isn't really a standard

00:00:48.720 --> 00:00:52.119
meta-object protocol for Scheme.

00:00:52.120 --> 00:00:53.519
That was an issue for me

00:00:53.520 --> 00:00:56.919
because I'm trying to make this cross-platform,

00:00:56.920 --> 00:00:59.639
and so I've done all of my work so far

00:00:59.640 --> 00:01:00.959
without a meta-object protocol

00:01:00.960 --> 00:01:02.439
because that's the easiest way to make it work

00:01:02.440 --> 00:01:04.879
on multiple Scheme implementations.

00:01:04.880 --> 00:01:07.359
But if there is a nice portable one

00:01:07.360 --> 00:01:12.559
that works on many implementations, I would use that, yes.

00:01:12.560 --> 00:01:14.999
It's just that so far it hasn't been necessary.

00:01:15.000 --> 00:01:19.279
I've been doing mostly functional reactive programming

00:01:19.280 --> 00:01:21.079
and React.js-like framework.

00:01:21.080 --> 00:01:23.239
I've created that for the GUI front end.

00:01:23.240 --> 00:01:26.199
And that's all the more I've needed so far.

00:01:26.200 --> 00:01:33.399
So, yeah. Oh, yeah, please, next question. Sure.

00:01:33.400 --> 00:01:39.599
So how will the GUI display code be R7RS compliant?

00:01:39.600 --> 00:01:45.079
As far as I know, there's no DL open in R7RS. That's right.

00:01:45.080 --> 00:01:48.879
Yeah, R7RS small is extremely small

00:01:48.880 --> 00:01:50.439
and does not have any features at all.

00:01:50.440 --> 00:01:54.799
But it does provide a conv expand macro.

00:01:54.800 --> 00:01:57.639
And this allows you to load in different code

00:01:57.640 --> 00:02:00.879
depending on which scheme implementation you're using.

00:02:00.880 --> 00:02:03.359
So basically, I'll have to write a different back end

00:02:03.360 --> 00:02:05.279
for each scheme implementation.

00:02:05.280 --> 00:02:06.639
And I think that's really

00:02:06.640 --> 00:02:10.919
the only way is possible at all,

00:02:10.920 --> 00:02:12.719
because there's no standardization.

00:02:12.720 --> 00:02:14.439
So essentially, the libraries

00:02:14.440 --> 00:02:15.719
that I've written for schemacs

00:02:15.720 --> 00:02:22.439
will become kind of a platform-independent way

00:02:22.440 --> 00:02:25.839
of writing GUIs for Scheme.

00:02:25.840 --> 00:02:27.119
It's just a matter of,

00:02:27.120 --> 00:02:28.679
will your Scheme implementation

00:02:28.680 --> 00:02:32.279
support the Schemacs GUI protocol?

00:02:32.280 --> 00:02:34.199
So I've kind of written my own protocol,

00:02:34.200 --> 00:02:36.679
and it's entirely R7 RSML compliant.

00:02:36.680 --> 00:02:38.239
It's all done with record,

00:02:38.240 --> 00:02:43.039
what are they called, record types.

00:02:43.040 --> 00:02:46.519
Do you think some of the Schemacs

00:02:46.520 --> 00:02:50.679
could be extracted into SFRIs since you've made it portable

00:02:50.680 --> 00:02:52.879
between scheme implementations?

00:02:52.880 --> 00:02:55.279
Yes, I would definitely like to do that.

00:02:55.280 --> 00:02:59.239
Probably first thing I'll do is start splitting up

00:02:59.240 --> 00:03:01.679
and publishing independent libraries

00:03:01.680 --> 00:03:04.319
on the Aku package manager.

00:03:04.320 --> 00:03:07.639
This is a kind of a package manager ecosystem for Scheme,

00:03:07.640 --> 00:03:11.679
and in particular R7RS Scheme.

00:03:11.680 --> 00:03:15.239
And it's also mirrored on the other package manager,

00:03:15.240 --> 00:03:18.279
Snowfort, just by the way.

00:03:18.280 --> 00:03:21.359
But yeah, and then I might be also,

00:03:21.360 --> 00:03:25.079
I've considered creating a SRFI for the lens library,

00:03:25.080 --> 00:03:27.399
which is based on the Haskell lens library.

00:03:27.400 --> 00:03:29.839
I don't think that exists yet in Scheme,

00:03:29.840 --> 00:03:34.319
so I thought that might make a good SRFI.

00:03:34.320 --> 00:03:36.719
Is there a recommended Scheme implementation?

00:03:36.720 --> 00:03:44.559
Guile is the reference implementation.

00:03:44.560 --> 00:03:47.279
It's the only one that works with GUI,

00:03:47.280 --> 00:03:51.359
but as I demonstrated in my presentation,

00:03:51.360 --> 00:03:52.599
the Emacs Lisp interpreter

00:03:52.600 --> 00:03:55.079
works on multiple schemes so far,

00:03:55.080 --> 00:04:00.039
and I've had trouble with some of the scheme compilers.

00:04:00.040 --> 00:04:04.839
But yeah, I would recommend Guile.

00:04:04.840 --> 00:04:07.719
But how would schemacs deal with

00:04:07.720 --> 00:04:10.039
Emacs's re-display architecture

00:04:10.040 --> 00:04:13.159
will be having its own display architecture?

00:04:13.160 --> 00:04:15.359
And if so, how will you handle

00:04:15.360 --> 00:04:18.479
things like overlays and images?

00:04:18.480 --> 00:04:25.239
Yeah, definitely. That's to be determined.

00:04:25.240 --> 00:04:31.279
So basically, the scheme way of doing things

00:04:31.280 --> 00:04:36.639
So, I've created this React-like programming framework.

00:04:36.640 --> 00:04:40.999
It's like ReactJS or Vue.js.

00:04:41.000 --> 00:04:45.119
That is just the API of how you write GUI code in Scheme.

00:04:45.120 --> 00:04:49.719
And each Scheme implementation

00:04:49.720 --> 00:04:52.279
will have its own GUI backend,

00:04:52.280 --> 00:04:55.599
which implements that Protocol.

00:04:55.600 --> 00:04:59.199
And so when it comes time to link

00:04:59.200 --> 00:05:03.079
the Emacs Lisp built-in functions

00:05:03.080 --> 00:05:08.279
that do these things like overlays and so on,

00:05:08.280 --> 00:05:11.079
we're going to have to come up with some way

00:05:11.080 --> 00:05:12.079
of modeling that

00:05:12.080 --> 00:05:15.799
using the scheme framework that I've designed.

00:05:15.800 --> 00:05:17.599
And I may have to make alterations

00:05:17.600 --> 00:05:22.039
specifically to support Emacs Lisp.

00:05:22.040 --> 00:05:28.559
I don't know yet. I haven't got that far.

00:05:28.560 --> 00:05:30.079
You were saying that you would like

00:05:30.080 --> 00:05:33.479
to get the most out of the 1300

00:05:33.480 --> 00:05:36.519
and something Emacs packages that exist.

00:05:36.520 --> 00:05:38.759
Are there technical blockers to doing them all

00:05:38.760 --> 00:05:44.039
or just a problem of getting enough people to jump into it?

00:05:44.040 --> 00:05:48.639
Yeah, it's just a matter of implementing enough

00:05:48.640 --> 00:05:50.839
of the Emacs built-in functions.

00:05:50.840 --> 00:05:57.079
Right now, there's kind of a big bug.

00:05:57.080 --> 00:05:59.359
I mentioned this also in the presentation.

00:05:59.360 --> 00:06:02.599
The stacks trace that you saw during my presentation,

00:06:02.600 --> 00:06:05.799
that is the biggest bug right now

00:06:05.800 --> 00:06:08.159
that's preventing me from running most other code.

00:06:08.160 --> 00:06:10.359
And I don't think other people

00:06:10.360 --> 00:06:13.039
will be able to contribute to the code base

00:06:13.040 --> 00:06:14.559
until I get that bug fixed,

00:06:14.560 --> 00:06:18.679
because it doesn't capture closures correctly.

00:06:18.680 --> 00:06:22.519
it doesn't behave like Emacs Lisp does,

00:06:22.520 --> 00:06:26.959
and that's the big problem.

00:06:26.960 --> 00:06:31.759
So once I get that worked out,

00:06:31.760 --> 00:06:35.599
then it's just a matter of implementing enough

00:06:35.600 --> 00:06:37.879
of the EmacsLisp built-in functions,

00:06:37.880 --> 00:06:40.679
these are the functions that are mostly implemented in C,

00:06:40.680 --> 00:06:42.879
implementing those in Scheme.

00:06:42.880 --> 00:06:45.959
And that, yeah, that's the thing

00:06:45.960 --> 00:06:47.839
that I'm going to need a lot of help with

00:06:47.840 --> 00:06:49.719
because there's quite a few of those APIs.

00:06:49.720 --> 00:06:53.519
But I imagine, I have no idea, no way of knowing,

00:06:53.520 --> 00:06:56.459
but I imagine we don't need 100% of them

00:06:56.460 --> 00:06:58.167
in order to run most of Elpa.

00:06:58.168 --> 00:07:05.084
We probably can get some of the important large Elpa packages

00:07:05.085 --> 00:07:12.719
like Magit and Org mode with just enough of the Emacs Lisp

00:07:12.720 --> 00:07:14.959
built-in functions to handle that.

00:07:14.960 --> 00:07:19.279
But we won't really know until we've tried.

00:07:19.280 --> 00:07:22.519
So yeah, I'll try to get this bug fixed right away.

00:07:22.520 --> 00:07:24.979
That way we can all start working on it together, hopefully.

00:07:24.980 --> 00:07:27.126
Highly relatable answer there.

00:07:27.127 --> 00:07:31.959
We'll burn that bridge when we're on it or something.

00:07:31.960 --> 00:07:34.559
What are your thoughts on chicken scheme?

00:07:34.560 --> 00:07:37.199
Will that be a good fit? Do you think?

00:07:37.200 --> 00:07:41.039
I think it will be, um, I, I did show

00:07:41.040 --> 00:07:44.959
trying to run chicken scheme in my, um, presentation

00:07:44.960 --> 00:07:48.839
and, uh, I ran up against some kind of issue,

00:07:48.840 --> 00:07:51.079
which I really don't know how to debug.

00:07:51.080 --> 00:07:55.879
Um, it's probably something to do with the, uh, pattern matcher.

00:07:55.880 --> 00:07:58.919
Um, I'm using the pattern matcher,

00:07:58.920 --> 00:08:00.599
uh, written by Alex shin,

00:08:00.600 --> 00:08:02.599
which seems to be the most portable.

00:08:02.600 --> 00:08:05.919
Pattern matcher, uh, for our seven RS scheme.

00:08:05.920 --> 00:08:13.519
But not all scheme compilers implement, what is it called?

00:08:13.520 --> 00:08:19.559
The macro, I can't remember what it's called.

00:08:19.560 --> 00:08:24.199
There's the macro expansion system for R7 RS small.

00:08:24.200 --> 00:08:27.199
All of these scheme implementations

00:08:27.200 --> 00:08:29.319
seem to have a slightly different take on how they work.

00:08:29.320 --> 00:08:33.919
And so that macro expander has been, for pattern matching,

00:08:33.920 --> 00:08:35.719
has been the biggest difficulty

00:08:35.720 --> 00:08:37.359
in making this code portable.

00:08:37.360 --> 00:08:42.239
And so I'm thinking of ways of maybe trying to ditch pattern matching,

00:08:42.240 --> 00:08:44.999
but that's such a useful feature and it's hard.

00:08:45.000 --> 00:08:49.879
So I don't know, we'll see if I can,

00:08:49.880 --> 00:08:52.439
if somebody can help me get it to work on chicken team,

00:08:52.440 --> 00:08:56.599
I'd really appreciate it.

00:08:56.600 --> 00:09:01.799
Can this implementation be used by Guile's Emacs Lisp mode?

00:09:01.800 --> 00:09:08.199
Guile's Emacs list mode. Okay. Yeah, good question.

00:09:08.200 --> 00:09:10.919
I did mention this last year in my presentation.

00:09:10.920 --> 00:09:13.719
Emacs list in Guile is totally different

00:09:13.720 --> 00:09:16.199
from what I've done.

00:09:16.200 --> 00:09:21.292
That implementation was written about 10 or 15 years ago.

00:09:21.293 --> 00:09:26.501
I can't remember exactly when. It is quite incomplete.

00:09:26.502 --> 00:09:36.542
I don't think it even runs most of the macro expanding code.

00:09:36.543 --> 00:09:39.679
Some of the code that is written

00:09:39.680 --> 00:09:42.479
for GNU Emacs in Emacs Lisp,

00:09:42.480 --> 00:09:45.679
where GNU Emacs is initializing itself,

00:09:45.680 --> 00:09:51.319
it can't even get the first file in that code.

00:09:51.320 --> 00:09:53.479
It hasn't been touched in 10 or 15 years.

00:09:53.480 --> 00:09:57.239
Initially, when I first started this project,

00:09:57.240 --> 00:09:59.159
I was using the parser

00:09:59.160 --> 00:10:02.319
for Guile's Emacs Lisp implementation,

00:10:02.320 --> 00:10:05.319
but it didn't give me things like source locations,

00:10:05.320 --> 00:10:10.639
so I had to rewrite that. And also, it wasn't portable.

00:10:10.640 --> 00:10:14.279
So yeah, because I want it to be portable,

00:10:14.280 --> 00:10:16.919
it's necessarily going to be not reliant

00:10:16.920 --> 00:10:19.119
on anything that's inside of the Guile library,

00:10:19.120 --> 00:10:21.479
including the Emacs LISP interpreter that's there.

00:10:21.480 --> 00:10:24.959
Maybe I could replace the Emacs LISP interpreter in Guile

00:10:24.960 --> 00:10:29.599
if Andy Wingo would be interested. All right.

00:10:29.600 --> 00:10:31.599
And I see we've got a few people

00:10:31.600 --> 00:10:34.039
that did jump into the BBB.

00:10:34.040 --> 00:10:37.159
I'm just going to quickly, oops.

00:10:37.160 --> 00:10:40.679
quickly try to make my text a little bigger

00:10:40.680 --> 00:10:42.799
so I can read a question that came here.

00:10:42.800 --> 00:10:48.479
I wonder if we can do some sort of pragmatic analysis

00:10:48.480 --> 00:10:49.959
on popular Emacs packages

00:10:49.960 --> 00:10:52.399
to see what list of functions they tend to depend on

00:10:52.400 --> 00:10:54.799
while a function calls down to the lower level.

00:10:54.800 --> 00:10:57.209
Yeah, that would be good.

00:10:57.210 --> 00:11:02.251
Somebody please do that for me. Awesome.

00:11:02.252 --> 00:11:05.439
Somebody's raising their hand. Divya.

00:11:05.440 --> 00:11:08.799
Let's see. Yeah, can you hear me?

00:11:08.800 --> 00:11:12.359
Yes, I can. Yeah, go ahead. Hello, thank you.

00:11:12.360 --> 00:11:14.079
Yeah, this is really awesome.

00:11:14.080 --> 00:11:16.959
I use Guile, and I love Guile,

00:11:16.960 --> 00:11:18.919
and I also love functional programming,

00:11:18.920 --> 00:11:21.599
so this is really nice that you took

00:11:21.600 --> 00:11:22.719
the declarative approach.

00:11:22.720 --> 00:11:26.319
One thing that I'm interested in is,

00:11:26.320 --> 00:11:29.839
are you also considering Racket in the scheme group?

00:11:29.840 --> 00:11:32.959
Because I know a lot of people do not consider Racket

00:11:32.960 --> 00:11:36.639
as a sort of scheme thing, because it grew out of it.

00:11:36.640 --> 00:11:39.519
Do you think you'll take something from Racket?

00:11:39.520 --> 00:11:42.119
Because I think Racket has

00:11:42.120 --> 00:11:44.519
a lot of good ideas that can be used.

00:11:44.520 --> 00:11:48.439
Yeah, I briefly looked at Racket's GUI library,

00:11:48.440 --> 00:11:51.879
but it's very, very heavily dependent

00:11:51.880 --> 00:11:53.839
on Racket's macro expander,

00:11:53.840 --> 00:11:57.679
which is, well, yeah, the macro expander

00:11:57.680 --> 00:11:59.679
is extremely complex for Racket,

00:11:59.680 --> 00:12:02.159
and I don't think it's possible to port it to any other scheme,

00:12:02.160 --> 00:12:07.679
as far as I know. But Racket is based on SheaScheme.

00:12:07.680 --> 00:12:14.479
And I am making an effort to port my code to Shea's scheme.

00:12:14.480 --> 00:12:18.639
I mentioned this earlier,

00:12:18.640 --> 00:12:22.159
but there's the Gwen Weinholdt Aku system,

00:12:22.160 --> 00:12:25.439
which allows you to translate R7RS to R6RS.

00:12:25.440 --> 00:12:28.519
And since Shea is an R6RS compiler,

00:12:28.520 --> 00:12:33.919
I did at one point get the Emacs Lisp interpreter

00:12:33.920 --> 00:12:34.919
to compile for Shea,

00:12:34.920 --> 00:12:38.239
although I think There's been a change

00:12:38.240 --> 00:12:40.479
either to Aku or somewhere in my own code base.

00:12:40.480 --> 00:12:42.879
It doesn't build anymore, and I'm not sure why.

00:12:42.880 --> 00:12:47.039
But I would also very much like to run this on Che.

00:12:47.040 --> 00:12:54.679
And I guess in that sense, we'll be able to work on Racket as well.

00:12:54.680 --> 00:12:56.199
There's also one other option.

00:12:56.200 --> 00:13:03.519
Alexis King has written an R7RS language package for Racket.

00:13:03.520 --> 00:13:05.039
I have not yet tried.

00:13:05.040 --> 00:13:08.479
running my package on R7RS for Racket.

00:13:08.480 --> 00:13:11.599
But that would be something interesting.

00:13:11.600 --> 00:13:12.919
Yes, I would like to try that.

00:13:12.920 --> 00:13:13.919
Yeah, it'll be interesting.

00:13:13.920 --> 00:13:15.839
I do have some experience with chairs.

00:13:15.840 --> 00:13:17.479
So, uh, if I can find some time,

00:13:17.480 --> 00:13:21.239
I'll, I'll, I'll certainly like to, I would appreciate.

00:13:21.240 --> 00:13:24.039
Yes. Yeah. Go ahead. Yeah.

00:13:24.040 --> 00:13:26.079
Another question I have is, like,

00:13:26.080 --> 00:13:29.199
what exactly is sort of, like, the, the approach is that

00:13:29.200 --> 00:13:31.479
you'll 1st want to do the interpreter

00:13:31.480 --> 00:13:33.799
and then have enough list functions.

00:13:33.800 --> 00:13:36.479
Uh, getting the max list functions

00:13:36.480 --> 00:13:38.119
interpreted or interpretable.

00:13:38.120 --> 00:13:40.999
And then go for GUI or do you want

00:13:41.000 --> 00:13:42.759
to sort of like go hand in hand

00:13:42.760 --> 00:13:45.679
is like we have the interpreter working on

00:13:45.680 --> 00:13:46.959
and we have also the GUI

00:13:46.960 --> 00:13:53.199
and we sort of use one for the other.

00:13:53.200 --> 00:13:56.479
Yeah, I consider the two tasks to be parallel.

00:13:56.480 --> 00:13:59.639
So I'm actually doing the GUI separately.

00:13:59.640 --> 00:14:05.519
The reason why is because the GUI for Schemacs

00:14:05.520 --> 00:14:10.279
is really just a clone of the look and feel of Emacs.

00:14:10.280 --> 00:14:14.679
It's not like an actual clone of the low-level C code

00:14:14.680 --> 00:14:16.039
that puts everything on screen.

00:14:16.040 --> 00:14:18.679
And I'm actually not really that interested

00:14:18.680 --> 00:14:21.439
in the low-level details

00:14:21.440 --> 00:14:23.479
of how Emacs draws things on screen either.

00:14:23.480 --> 00:14:26.839
I think it has a lot of historical baggage,

00:14:26.840 --> 00:14:28.839
and I'm actually trying to move away from that.

00:14:28.840 --> 00:14:31.759
So that was part of the reason why I started

00:14:31.760 --> 00:14:36.399
with this React.js or Vue.js-like Reactive GUI framework.

00:14:36.400 --> 00:14:39.519
So that GUI part is completely separate.

00:14:39.520 --> 00:14:42.239
And I want to worry about the details

00:14:42.240 --> 00:14:46.719
of how we make the GUI look and feel

00:14:46.720 --> 00:14:50.319
similar in Schemacs, similar to GNU Emacs.

00:14:50.320 --> 00:14:54.799
In Schemacs, using the Emacs programming language,

00:14:54.800 --> 00:14:59.319
I think that's something that we should worried about

00:14:59.320 --> 00:15:03.399
after we have enough of the Emacs list implemented.

00:15:03.400 --> 00:15:04.919
Yeah, that makes sense.

00:15:04.920 --> 00:15:06.679
There are sort of, I'm a bit worried.

00:15:06.680 --> 00:15:10.599
So, I don't know if, so one of my presentations

00:15:10.600 --> 00:15:11.479
is going to be tomorrow.

00:15:11.480 --> 00:15:13.119
I'm working on something called Emacs Viewer.

00:15:13.120 --> 00:15:15.319
It's a document viewer in Emacs.

00:15:15.320 --> 00:15:17.679
And essentially one of the issues that I'm up against

00:15:17.680 --> 00:15:20.359
is that Emacs's display system

00:15:20.360 --> 00:15:25.439
is sort of very let's say, not flexible.

00:15:25.440 --> 00:15:31.839
When trying to analyze where this inflexibility comes from,

00:15:31.840 --> 00:15:35.759
I don't think it's just the display architecture.

00:15:35.760 --> 00:15:38.319
I think parts of eLISP itself

00:15:38.320 --> 00:15:43.599
are connected to the display architecture.

00:15:43.600 --> 00:15:48.399
The notion of a cell in a buffer,

00:15:48.400 --> 00:15:52.199
itself is connected tightly to

00:15:52.200 --> 00:15:54.519
how the re-display architecture works.

00:15:54.520 --> 00:15:57.199
So I think you'll have to sort of figure out

00:15:57.200 --> 00:16:00.679
what exactly you can salvage from ELISP

00:16:00.680 --> 00:16:05.199
without taking the display architecture baggage.

00:16:05.200 --> 00:16:08.001
That's right. I do anticipate

00:16:08.002 --> 00:16:09.876
that's going to be fairly challenging.

00:16:09.877 --> 00:16:14.584
It's all Turing-complete,

00:16:14.585 --> 00:16:17.879
so I imagine we're probably going to end up

00:16:17.880 --> 00:16:21.039
creating something like an emulator

00:16:21.040 --> 00:16:24.319
for the Emacs Lisp display architecture in Scheme

00:16:24.320 --> 00:16:27.559
that will somehow translate down

00:16:27.560 --> 00:16:30.039
to the React-like protocol that I've written.

00:16:30.040 --> 00:16:32.719
But yeah, I don't I haven't that's nice.

00:16:32.720 --> 00:16:36.319
No, this is this is very exciting. Yeah. Oh Yes, it is.

00:16:36.320 --> 00:16:39.559
Yeah, I'm glad so like a lot of people have told me

00:16:39.560 --> 00:16:41.679
that they really Are excited to see this project

00:16:41.680 --> 00:16:42.719
and this really helps me

00:16:42.720 --> 00:16:46.399
You know keep focused on this project

00:16:46.400 --> 00:16:48.319
because a lot of people are very interested.

00:16:48.320 --> 00:16:50.359
So It's so I'd like to move on

00:16:50.360 --> 00:16:52.159
to a couple of questions from the past.

00:16:52.160 --> 00:16:54.479
We're starting to build up a good backlog.

00:16:54.480 --> 00:16:59.719
Thank you for that. Yeah Next question from the pad I have.

00:16:59.720 --> 00:17:02.239
Can you tell us more about the show stopping bug?

00:17:02.240 --> 00:17:04.159
How to squash it? How can people help?

00:17:04.160 --> 00:17:08.799
OK, well, that one, unfortunately, I think,

00:17:08.800 --> 00:17:11.679
unless you're really a scheme genius

00:17:11.680 --> 00:17:13.799
and you can really read my code

00:17:13.800 --> 00:17:15.479
and immediately understand how it all works,

00:17:15.480 --> 00:17:18.319
I don't think you'd be able to help.

00:17:18.320 --> 00:17:22.599
It shouldn't be too difficult for me to fix.

00:17:22.600 --> 00:17:26.639
So it has to do with how closures work.

00:17:26.640 --> 00:17:30.719
And a closure is basically an object

00:17:30.720 --> 00:17:33.159
that can be created with stuff that's on the stack.

00:17:33.160 --> 00:17:37.079
And this is a feature, I think,

00:17:37.080 --> 00:17:39.679
that was introduced with Emacs 27.

00:17:39.680 --> 00:17:40.879
I can't remember exactly,

00:17:40.880 --> 00:17:43.439
but it's actually a relatively recent feature.

00:17:43.440 --> 00:17:45.879
It was ever since they introduced

00:17:45.880 --> 00:17:50.999
lexically scoped variable bindings in Emacs Lisp.

00:17:51.000 --> 00:17:54.519
And so yeah, the problem is that

00:17:54.520 --> 00:17:59.839
when you create like a let structure

00:17:59.840 --> 00:18:01.799
and you could declare a variable in the let.

00:18:01.800 --> 00:18:05.399
And then you create inside of that a second let structure,

00:18:05.400 --> 00:18:07.239
and you have a lambda inside of that.

00:18:07.240 --> 00:18:11.319
And the lambda references or uses a variable

00:18:11.320 --> 00:18:14.399
that was declared in the outer let binding.

00:18:14.400 --> 00:18:18.279
That outer let binding is somewhere on the stack.

00:18:18.280 --> 00:18:22.999
And the lambda you can actually return it as a value.

00:18:23.000 --> 00:18:25.319
So when you do return that lambda,

00:18:25.320 --> 00:18:27.679
it has to have a note somewhere inside

00:18:27.680 --> 00:18:31.279
that says, by the way, I'm using that variable.

00:18:31.280 --> 00:18:34.359
So you need to capture it and restore it to the stack

00:18:34.360 --> 00:18:38.199
whenever this lambda is applied, whenever you execute it.

00:18:38.200 --> 00:18:40.959
And that is where the error is.

00:18:40.960 --> 00:18:44.399
It's not capturing the stack variable properly.

00:18:44.400 --> 00:18:46.879
And I think what I'm going to do,

00:18:46.880 --> 00:18:49.759
I haven't looked into it in detail yet

00:18:49.760 --> 00:18:53.279
because I've gone back to GUI stuff recently,

00:18:53.280 --> 00:18:55.479
but what I'm going to do, I think,

00:18:55.480 --> 00:18:57.799
is just do a static analysis

00:18:57.800 --> 00:18:59.079
of the code inside of the Lambda

00:18:59.080 --> 00:19:02.919
and see which symbols are being used,

00:19:02.920 --> 00:19:05.079
and then just capture all of those

00:19:05.080 --> 00:19:07.559
and place those into the record type

00:19:07.560 --> 00:19:09.519
that stores the lambda.

00:19:09.520 --> 00:19:12.679
That's how I'm going to fix that, I think.

00:19:12.680 --> 00:19:15.999
I hope anyway that's going to work.

00:19:16.000 --> 00:19:17.239
You never know with bugs.

00:19:17.240 --> 00:19:21.759
They're always a little bit tricky. Okay, next question.

00:19:21.760 --> 00:19:23.119
Are there performance concerns

00:19:23.120 --> 00:19:28.479
with implementing certain C primitives in PeerScheme?

00:19:28.480 --> 00:19:32.879
So who is it? The famous computer scientist that said

00:19:32.880 --> 00:19:35.879
premature optimization is the root of all evil.

00:19:35.880 --> 00:19:39.799
I think it was the guy who invented the A star algorithm.

00:19:39.800 --> 00:19:42.719
His name escapes me at the minute.

00:19:42.720 --> 00:19:49.359
But yeah, I'm not concerned about performance yet,

00:19:49.360 --> 00:19:52.119
although most of the scheme compilers that I have seen,

00:19:52.120 --> 00:19:56.999
especially Shea and Gambit

00:19:57.000 --> 00:20:02.039
have extremely good performance characteristics.

00:20:02.040 --> 00:20:03.679
And so I think there won't be

00:20:03.680 --> 00:20:05.879
too much difficulty with performance,

00:20:05.880 --> 00:20:08.759
even implementing some of the C stuff.

00:20:08.760 --> 00:20:10.759
And besides, a lot of the GUI stuff

00:20:10.760 --> 00:20:12.719
is already written in C anyway.

00:20:12.720 --> 00:20:14.399
I mean, it would be cool

00:20:14.400 --> 00:20:16.879
if we had a scheme GUI library

00:20:16.880 --> 00:20:18.599
that painted to a canvas,

00:20:18.600 --> 00:20:21.639
maybe for a Wayland implementation or something.

00:20:21.640 --> 00:20:29.079
But I don't know. It's not a concern for me, performance.

00:20:29.080 --> 00:20:32.079
Okay, there are a few more questions. I do want to mention

00:20:32.080 --> 00:20:33.839
that the stream has cut away at this point,

00:20:33.840 --> 00:20:36.279
but we're still recording live.

00:20:36.280 --> 00:20:38.799
All of this will be put up on the website

00:20:38.800 --> 00:20:40.399
and so on like that.

00:20:40.400 --> 00:20:44.199
So, I appreciate all the enthusiastic questions

00:20:44.200 --> 00:20:47.799
and you're kind of tanking through them all.

00:20:47.800 --> 00:20:52.799
Me too. I love how many questions I'm getting.

00:20:52.800 --> 00:20:54.039
This is very encouraging

00:20:54.040 --> 00:20:55.999
and it really makes me want to keep on working on it.

00:20:56.000 --> 00:20:56.879
So it's great.

00:20:56.880 --> 00:21:00.199
I'm so glad to hear that because that's exactly the message

00:21:00.200 --> 00:21:01.439
I think you should be receiving.

00:21:01.440 --> 00:21:04.159
This is a fantastic project. Thank you so much.

00:21:04.160 --> 00:21:08.439
I'll just say so myself. If the project is successful,

00:21:08.440 --> 00:21:11.479
are you worried about a possible split in the community

00:21:11.480 --> 00:21:15.599
between Schemacs and GNU Emacs?

00:21:15.600 --> 00:21:18.959
Oh, I have thought about that.

00:21:18.960 --> 00:21:24.039
And I really don't know what's going to happen.

00:21:24.040 --> 00:21:26.239
There seems to be already a huge demand

00:21:26.240 --> 00:21:30.439
for a scheme-based, a modern scheme-based editor.

00:21:30.440 --> 00:21:33.399
You know, the Edwin scheme for MIT scheme

00:21:33.400 --> 00:21:37.279
hasn't been touched since like 1987 or something,

00:21:37.280 --> 00:21:41.439
maybe 1993 or, but anyway.

00:21:41.440 --> 00:21:43.159
There seems to be huge demand.

00:21:43.160 --> 00:21:45.119
And so I guess a lot of people

00:21:45.120 --> 00:21:47.679
who are currently using GNU Emacs

00:21:47.680 --> 00:21:49.079
will probably just switch over

00:21:49.080 --> 00:21:50.479
because they've been wanting

00:21:50.480 --> 00:21:53.159
something like this for a very long time.

00:21:53.160 --> 00:21:56.559
And then, I mean, is that going to cause fragmentation?

00:21:56.560 --> 00:21:58.679
Is it really a big deal, though?

00:21:58.680 --> 00:22:02.479
I mean, it's all GPL-licensed code.

00:22:02.480 --> 00:22:08.759
I mean, I think a rising tide raises all the ships at the same time.

00:22:08.760 --> 00:22:13.279
So, yeah, also, the last thing I want to say about that

00:22:13.280 --> 00:22:18.999
is I would like to contribute some of what I do in Schemacs

00:22:19.000 --> 00:22:24.399
back into GNU Emacs, if I can. So, for example, I'm going

00:22:24.400 --> 00:22:25.959
to be working on like a canvas library

00:22:25.960 --> 00:22:27.879
where you can have interactive canvases

00:22:27.880 --> 00:22:30.879
and you know you can actually like draw pictures

00:22:30.880 --> 00:22:33.559
and put things with the mouse and drag things around.

00:22:33.560 --> 00:22:36.079
And I was thinking you know

00:22:36.080 --> 00:22:37.667
if if I can figure out how that works

00:22:37.668 --> 00:22:41.917
maybe I can write something like that for Emacs

00:22:41.918 --> 00:22:47.759
or GNU Emacs using the Cairo library, you know,

00:22:47.760 --> 00:22:49.319
SVG rendering library that they have.

00:22:49.320 --> 00:22:51.319
So, you know, if I have time,

00:22:51.320 --> 00:22:55.799
I would like to continue contributing to GNU Emacs as well.

00:22:55.800 --> 00:22:57.839
I'm sorry, what was the name of the library you mentioned?

00:22:57.840 --> 00:23:01.039
Oh, Cairo, like Cairo.

00:23:01.040 --> 00:23:07.599
Oh, Cairo, yeah. Absolutely. I spelled that poorly.

00:23:07.600 --> 00:23:12.519
The dream of never needing to change to the web browser.

00:23:12.520 --> 00:23:18.376
Would schemacs bring us closer to that? I hope so.

00:23:18.377 --> 00:23:21.709
That's also a dream of mine.

00:23:21.710 --> 00:23:26.479
The part of the reason why I wanted to work, you know,

00:23:26.480 --> 00:23:30.999
make sure I had a really good workable GUI framework

00:23:31.000 --> 00:23:32.626
is so that I could, you know,

00:23:32.627 --> 00:23:34.879
we could write apps like, you know,

00:23:34.880 --> 00:23:38.759
they have a mastodon client written in Emacs Lisp.

00:23:38.760 --> 00:23:42.199
that would be so nice to have this, you know,

00:23:42.200 --> 00:23:43.439
a really nice Mastodon client

00:23:43.440 --> 00:23:47.479
that was right inside of, you know, our scheme environment

00:23:47.480 --> 00:23:50.039
where we were doing our text editing and other stuff.

00:23:50.040 --> 00:23:52.079
I've always wanted something like that,

00:23:52.080 --> 00:23:53.799
or it would be cool to have

00:23:53.800 --> 00:23:56.319
just a slightly nicer GUI for Magit.

00:23:56.320 --> 00:24:04.199
So, yeah, I mean, like, yeah, being able to avoid the web entirely

00:24:04.200 --> 00:24:08.199
and just be able to like, you know, do social networking

00:24:08.200 --> 00:24:11.439
and do your GitHub stuff,

00:24:11.440 --> 00:24:14.759
everything from within Emacs or Schemacs in this case,

00:24:14.760 --> 00:24:16.919
that's a dream of mine as well.

00:24:16.920 --> 00:24:20.079
And so I hope that that's where we end up in a couple of years.

00:24:20.080 --> 00:24:29.999
The sooner the better. Anything, just double checking.

00:24:30.000 --> 00:24:33.319
Anything specific other than minimalism

00:24:33.320 --> 00:24:35.799
that made you choose Scheme over Commonwealth?

00:24:35.800 --> 00:24:40.199
Oh, yeah, it's kind of a philosophical question.

00:24:40.200 --> 00:24:45.559
So a couple of things. First of all, it was a conversation

00:24:45.560 --> 00:24:47.399
I had with William Byrd,

00:24:47.400 --> 00:24:50.519
and he's a guy who makes the Mini Conran framework for Scheme.

00:24:50.520 --> 00:24:52.879
It was his PhD thesis.

00:24:52.880 --> 00:24:57.119
He worked with, I'm sorry, I just can't remember his name.

00:24:57.120 --> 00:24:59.679
He worked at the University of Indiana.

00:24:59.680 --> 00:25:03.839
Another famous Scheme or Lisp person was there.

00:25:03.840 --> 00:25:06.279
Friedman, Dan Friedman was his advisor.

00:25:06.280 --> 00:25:09.159
Yeah, big name in Lisp.

00:25:09.160 --> 00:25:12.839
Anyway, so I was talking with William Byrd,

00:25:12.840 --> 00:25:14.639
and I'm a huge Haskell fan,

00:25:14.640 --> 00:25:16.919
and he told me why he didn't like Haskell at all,

00:25:16.920 --> 00:25:19.639
and kind of convinced me to try Scheme out.

00:25:19.640 --> 00:25:22.759
And what I really like about Scheme is,

00:25:22.760 --> 00:25:25.399
yeah, like you said, the minimalism,

00:25:25.400 --> 00:25:29.839
but it's more that it is very close

00:25:29.840 --> 00:25:34.879
to the mathematical framework of lambda calculus.

00:25:34.880 --> 00:25:38.519
Haskell is probably the most pure

00:25:38.520 --> 00:25:39.919
lambda calculus that I've ever used,

00:25:39.920 --> 00:25:45.519
but Scheme is like the simply typed lambda calculus,

00:25:45.520 --> 00:25:47.799
and That just appeals to me.

00:25:47.800 --> 00:25:50.839
I think, you know, if you have this tiny, tiny core language

00:25:50.840 --> 00:25:55.599
from which all of the computing can be defined,

00:25:55.600 --> 00:25:57.119
I think it's kind of a shame

00:25:57.120 --> 00:26:00.079
that so far we just haven't explored that space yet.

00:26:00.080 --> 00:26:03.639
I mean, there's compared to JavaScript or Python,

00:26:03.640 --> 00:26:05.879
there's very little scheme code out there

00:26:05.880 --> 00:26:08.239
and it could be doing so much. And I would just like to try

00:26:08.240 --> 00:26:10.159
and expand the scheme ecosystem

00:26:10.160 --> 00:26:12.999
and see just what this tiny little language can do.

00:26:13.000 --> 00:26:14.479
And I think we haven't even seen

00:26:14.480 --> 00:26:16.839
a fraction of what it can do.

00:26:16.840 --> 00:26:22.399
That's why I've chosen scheme.

00:26:22.400 --> 00:26:24.719
Divya, I see you've got a bunch more comments.

00:26:24.720 --> 00:26:26.679
I think we're just about close to our time here,

00:26:26.680 --> 00:26:28.279
but if you wanted to jump back in,

00:26:28.280 --> 00:26:30.519
I'm sorry, I had to cut you off a little before.

00:26:30.520 --> 00:26:33.959
No, it's fine. No, it's fine.

00:26:33.960 --> 00:26:36.599
I think I agree with most of what he said.

00:26:36.600 --> 00:26:40.679
So, yeah, thank you so much.

00:26:40.680 --> 00:26:45.159
Um, closing thoughts, Ramin.

00:26:45.160 --> 00:26:51.639
Yeah, I guess everybody, please, if you're interested,

00:26:51.640 --> 00:26:56.719
keep watching my Mastodon and keep watching my Codeberg.

00:26:56.720 --> 00:27:01.559
I'm going to try and squash this bug as quickly as I can.

00:27:01.560 --> 00:27:03.279
I hope early next year,

00:27:03.280 --> 00:27:07.519
hopefully not much later than February,

00:27:07.520 --> 00:27:12.039
I'll actually be able to start taking in contributions

00:27:12.040 --> 00:27:16.719
for some of the Emacs Lisp built-ins in the code base.

00:27:16.720 --> 00:27:21.959
So, please keep watching. The pace of my development

00:27:21.960 --> 00:27:24.279
has increased pretty rapidly recently,

00:27:24.280 --> 00:27:25.839
and I think we're pretty close

00:27:25.840 --> 00:27:29.119
to getting something that we can all use together.

00:27:29.120 --> 00:27:31.719
Thank you once again for your amazing talk,

00:27:31.720 --> 00:27:34.039
for your exceptional work,

00:27:34.040 --> 00:27:36.599
and for jumping in, doing the live Q&A,

00:27:36.600 --> 00:27:40.039
rolling with us here as we have yet another

00:27:40.040 --> 00:27:42.079
We'll See How It Goes conference.

00:27:42.080 --> 00:27:44.279
It's been just amazing so far,

00:27:44.280 --> 00:27:46.839
and this talk is no small part of that. Thank you.

00:27:46.840 --> 00:27:50.279
Oh, thank you so much. Yeah. OK, cool.

00:27:50.280 --> 00:27:51.834
And thanks for all the questions, everyone.