updatesHEADmaster

1 files changed, 1531 insertions, 0 deletions

diff --git a/2025/captions/emacsconf-2025-schemacs--one-year-progress-update-schemacs-formerly-gypsum--ramin-honary--answers.vtt b/2025/captions/emacsconf-2025-schemacs--one-year-progress-update-schemacs-formerly-gypsum--ramin-honary--answers.vtt
new file mode 100644
index 00000000..738e9779
--- /dev/null
+++ b/2025/captions/emacsconf-2025-schemacs--one-year-progress-update-schemacs-formerly-gypsum--ramin-honary--answers.vtt
@@ -0,0 +1,1531 @@
+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.