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.