WEBVTT NOTE Q: I think that Kiczalez et al.'s metaobject protocol has a scheme implementation, does this mean schemacs will be metaobject-changeable in practice? 00:00:00.000 --> 00:00:01.091 [oops, forgot to start] [Corwin]: ... object protocol 00:00:01.092 --> 00:00:03.839 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 [Ramin]: 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. NOTE Q: How will the GUI display code be r7rs compliant afaik there is no dlopen in r7rs? 00:01:33.400 --> 00:01:39.599 [Corwin]: So how will the GUI display code be R7RS compliant? 00:01:39.600 --> 00:01:44.486 As far as I know, there's no DL open in R7RS. 00:01:44.487 --> 00:01:45.079 [Ramin]: 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 R7RS small 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. NOTE Q: Do you think some of schemacs could be extracted into SRFIs since you have made it portable between scheme implementations? 00:02:43.040 --> 00:02:46.519 [Corwin]: 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 [Ramin]: 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 Akku 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. NOTE Q: Is there a recommended scheme implementation or does it try to be as portable as possible? 00:03:34.320 --> 00:03:36.719 [Corwin]: Is there a recommended Scheme implementation? 00:03:36.720 --> 00:03:44.559 [Ramin]: 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. NOTE Q: How would Schemacs deal with Emacs' (re)display architecture? Would it be having its own display architecture? If so, how can it be compatible with things like overlays, images, etc.? From what I know, Emacs is extremely idiosyncratic here. 00:04:04.840 --> 00:04:07.719 [Corwin]: 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 [Ramin]: 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. NOTE Q: You were saying that you'd like to get "most" of the one thousand three hundred and something Emacs packages done. Is there a technical blocker to doing them all? Or just a problem of getting enough people in to help and start writing scheme? 00:05:28.560 --> 00:05:30.079 [Corwin]: 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 [Ramin]: 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 stacktrace 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 [Corwin]: Highly relatable answer there. 00:07:27.127 --> 00:07:31.959 We'll burn that bridge when we're on it or something. NOTE Q: What are you thoughts on Chicken Scheme? Would it be a good fit? 00:07:31.960 --> 00:07:34.559 [Corwin]: 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 [Ramin]: 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 Shinn, 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 R7RS 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. NOTE Q: Can this emacs lisp implementation be used by Guile's emacs lisp "mode"? 00:08:56.600 --> 00:09:01.799 [Corwin]: Can this implementation be used by Guile's Emacs Lisp mode? 00:09:01.800 --> 00:09:08.199 [Ramin]: Guile's Emacs Lisp 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. NOTE Q: I wonder if we could do some sort of programmatic analysis on popular Emacs packages to see what list of functions they tend to depend upon, follow function calls down to the lowest level 00:10:42.800 --> 00:10:48.479 [Corwin]: 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 [Ramin]: Yeah, that would be good. 00:10:57.210 --> 00:10:59.382 Somebody please do that for me. 00:10:59.383 --> 00:11:05.439 [Corwin]: Awesome. Somebody's raising their hand. Divya. 00:11:05.440 --> 00:11:08.799 [Divya]: Let's see. Yeah, can you hear me? 00:11:08.800 --> 00:11:11.734 [Corwin]: Yes, we can. Yeah, go ahead. 00:11:11.735 --> 00:11:12.359 [Divya]: 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. NOTE Q: Do you think there is an opportunity to use Racket? 00:11:36.640 --> 00:11:39.519 [Divya]: Do you think you'll take something from Racket? 00:11:39.520 --> 00:11:40.424 Because I think Racket has 00:11:40.425 --> 00:11:42.090 a lot of good ideas that can be used. 00:11:42.091 --> 00:11:48.439 [Ramin]: 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 Chez Scheme. 00:12:07.680 --> 00:12:14.479 And I am making an effort to port my code to Chez'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 Akku 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 Chez 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 Chez, 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 Akku 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 Chez. 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 [Divya]: Yeah, it'll be interesting. 00:13:13.920 --> 00:13:15.839 I do have some experience with Chez. 00:13:15.840 --> 00:13:17.479 So, uh, if I can find some time, 00:13:17.480 --> 00:13:20.006 I'll, I'll, I'll certainly like to, 00:13:20.007 --> 00:13:21.239 [Ramin]: I would very much appreciate. 00:13:21.240 --> 00:13:24.039 Yes. Yeah. Go ahead. Yeah. NOTE Q: Shouldn't it be enough to just implement the builtin functions? Most of the commands are written in Emacs Lisp, right? 00:13:24.040 --> 00:13:26.079 [Divya]: 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 first want to do the interpreter 00:13:31.480 --> 00:13:33.799 and then have enough Elisp functions, 00:13:33.800 --> 00:13:36.479 getting the GNU Emacs Lisp 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 [Ramin]: 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 Lisp implemented. 00:15:03.400 --> 00:15:04.919 [Divya]: 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 [Ramin]: 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:35.256 [Divya]: No, this is this is very exciting. Yeah. 00:16:35.257 --> 00:16:36.319 [Ramin]: Oh, yes, it is. 00:16:36.320 --> 00:16:39.559 Yeah, I'm glad. 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 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 [Corwin]: 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, Divya. Next question from the pad I have. NOTE Q: Tell us more about this show-stopping bug! How to squash it? Can people help? 00:16:59.720 --> 00:17:02.239 [Corwin]: 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 [Ramin]: 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. NOTE Q: Are there performance concerns with implementing certain C primitives in pure scheme? 00:19:21.760 --> 00:19:23.119 [Corwin]: Are there performance concerns 00:19:23.120 --> 00:19:28.479 with implementing certain C primitives in pure Scheme? 00:19:28.480 --> 00:19:32.879 [Ramin]: 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* 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 Chez 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 [Corwin]: 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 [Ramin]: 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:07.051 I'll just say so myself. NOTE Q: If this project is successful, are you worried about a possible split in the community between Schemacs and GNU Emacs users? 00:21:07.052 --> 00:21:08.439 [Corwin]: 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 [Ramin]: 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. NOTE Q: The dream of never even needing to change to the web browser - would schemacs bring us closer to that? 00:23:07.600 --> 00:23:12.519 [Corwin]: The dream of never needing to change to the web browser. 00:23:12.520 --> 00:23:17.818 Would schemacs bring us closer to that? 00:23:17.819 --> 00:23:18.376 [Ramin]: 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. NOTE Q: Anything specific other than minimalism that made you choose Scheme over Common Lisp? 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 Common Lisp? 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 miniKanren 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 [Corwin]: 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 [Divya]: 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. NOTE Closing thoughts 00:26:40.680 --> 00:26:45.159 [Corwin]: Um, closing thoughts, Ramin. 00:26:45.160 --> 00:26:51.639 [Ramin]: 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 [Corwin]: 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 [Ramin]: Oh, thank you so much. Yeah. OK, cool. 00:27:50.280 --> 00:27:51.834 And thanks for all the questions, everyone.