diff options
Diffstat (limited to '2025/captions/emacsconf-2025-schemacs--one-year-progress-update-schemacs-formerly-gypsum--ramin-honary--answers.vtt')
| -rw-r--r-- | 2025/captions/emacsconf-2025-schemacs--one-year-progress-update-schemacs-formerly-gypsum--ramin-honary--answers.vtt | 1586 |
1 files changed, 1586 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..0ec71aed --- /dev/null +++ b/2025/captions/emacsconf-2025-schemacs--one-year-progress-update-schemacs-formerly-gypsum--ramin-honary--answers.vtt @@ -0,0 +1,1586 @@ +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. |