WEBVTT 00:00.000 --> 00:21.520 Hello, everyone. I'm Jessica Talon. I've worked on Activity Pop, but I'm currently working 00:21.520 --> 00:30.400 at the Sprite Lean Institute, and I'm Scheme Programmer, all of our work as Sprite Lean is 00:30.400 --> 00:37.600 in Scheme, in Giles Scheme, and I'm also a long time EMAX user, which might surprise you if you've 00:37.600 --> 00:45.960 read the title of this talk. I've been using EMAX for, well, I say a long time, I think probably 00:45.960 --> 00:52.840 in the audience has been, this was in short time, but at least 14 years or so. Quickly, 00:52.840 --> 01:00.280 Sprite Lean, we do a lot of work on Giles Goblins, and who'd, which is a Giles Scheme 01:00.280 --> 01:06.920 to WebAssembly, we work developing technologies for the decentralized web, and we're a US 01:06.920 --> 01:12.360 nonprofit, if you're interested, donate. But this talk is largely not about Sprite Lean, 01:12.360 --> 01:22.920 but Scheme itself, and who here is a Scheme developer, Giles Scheme developer, who here 01:22.920 --> 01:31.080 doesn't use EMAX for that? Great, maybe talk to me, but this is a sentiment I've seen several 01:31.080 --> 01:36.200 times, which is, is people asking to learn, like, they want to learn Scheme, they want to 01:36.200 --> 01:44.120 start with Giles Scheme, and the advice is learn EMAX first, and I actually think this isn't 01:44.120 --> 01:53.320 bad advice because of how poor the situation is outside of EMAX for developing Scheme, 01:53.320 --> 02:00.120 Scheme code, and I really want more people to use Scheme, and I think, well, EMAX is a 02:00.120 --> 02:10.040 great editor, it's a weird editor as well, you know, like buffers, windows, and copy and paste, 02:10.040 --> 02:18.520 the kill and yang, and it's got weird defaults, it's quite a burden to learn if you're a new 02:18.520 --> 02:25.720 time developer, and so what are other people using? I found this graph very confusing because 02:25.800 --> 02:32.120 none of the percent's add up to 100, I think people can pick multiple options, this is from 02:32.120 --> 02:39.640 Stack Overflow, it was kind of difficult to find stats on this, but you can see, like VS code is here, 02:39.640 --> 02:49.960 VIM, you've got nano surprisingly, sublime text, Z, and unfortunately EMAX just isn't on 02:50.040 --> 02:58.840 here, so I'm guessing we don't fill in the survey, but more people should use EMAX, it's great, 03:00.120 --> 03:07.640 and why is it great? Specifically, why is it great for skiing? You can see here, sorry it's a little 03:07.640 --> 03:15.480 small, you can see here, it's obviously got great syntax highlighting, and it's got great 03:15.560 --> 03:23.240 intention, which I'm going to speak about more in a little bit, but skimming 03:23.240 --> 03:28.840 indentation is not like it is in other languages, but EMAX handles it perfectly as you'd expect, 03:30.040 --> 03:36.680 a lot of people use parodet or smart prints, I actually don't, even in EMAX, and it's got 03:36.680 --> 03:43.480 great ripple integration with geyser and things like that, it also has the info manual, which is 03:43.480 --> 03:48.280 really great, you can see here in the screenshot, you can actually see where my cursor is due to how 03:49.080 --> 03:57.480 genome takes screenshots, but I'm over the HT variable in this hash reset, and it's helpful in 03:57.480 --> 04:05.480 the bottom here, telling me that it's expecting the table here, and then the next values will be key 04:05.480 --> 04:11.000 in value, and I have my ripple here, and I'm evaluating some functions and seeing the answers, 04:11.160 --> 04:17.240 it's a really good environment to develop in, and indeed the documentation is right there in EMAX, 04:17.240 --> 04:22.360 I can just ask it what this function is, and this hash reset, and I'll tell you what it is, 04:22.360 --> 04:28.280 and the definition that can jump directly to the manual or the source code, this is why EMAX 04:28.280 --> 04:36.600 is such a great development, environment for skim, are there any other development environments for 04:36.680 --> 04:42.520 skim, that are really great, I've got Dr. Rackett here, another skim, I don't think it's 04:42.520 --> 04:47.880 like great for developing non-Rackett skim, maybe other people have had more look with it, 04:49.480 --> 04:59.080 and this is a screenshot from the SICP lectures, so the chalkboard is a popular choice at least 04:59.080 --> 05:06.440 back then, but it didn't make it onto the survey, but what's the status in 05:06.440 --> 05:13.560 some of these more mainstream editors, this is Z, which was on the survey, this is actually not 05:13.800 --> 05:18.920 directly out of the box, they used to have the skim plugin included out of the box, but this was the 05:18.920 --> 05:25.480 highest rated one, and it looks actually okay, right, like you're seeing some syntax highlighting, 05:27.480 --> 05:34.600 and that looks good, and then this is a blind Texas proprietary, so not something I'm likely to use, 05:34.600 --> 05:42.280 but you know, if this does actually come out the box with skim, and this is the goblin source 05:42.280 --> 05:48.920 code, and you can see it's like highlighting this pretty well, so what's the problem, this looks 05:48.920 --> 05:55.800 great, right, like why am I speaking about this, it's great in that it has syntax highlighting, 05:57.000 --> 06:04.440 but the second point of indentation, I would say is almost more important, and what I found 06:04.440 --> 06:14.520 when I tried to program skim outside of e-max to be the biggest barrier, this was, I, you know, 06:14.520 --> 06:21.080 you take for granted what e-max will do for you there, and it doesn't have any of these other things 06:21.080 --> 06:28.760 either, you know, no power, I don't know, grapple and no good documentation integration, 06:29.720 --> 06:35.800 and this indentation, what do I mean by this, I've got the same source code on both sides, 06:36.360 --> 06:43.320 this one's Z, but similar in other editors, and this is e-max in the terminal, and I have this 06:43.320 --> 06:52.280 let block, and I've finished defining this first binding, and if hit enter, and e-max has 06:52.280 --> 07:00.520 helpedfully put my cursor right where I'd want to start the next binding, right, you know, 07:00.520 --> 07:08.520 in line, and I've done the same in Z, and it's just taken what the last indentation was, 07:09.080 --> 07:15.880 and so I will have to go there and press space a lot of times to go up, and actually a lot of editors 07:16.840 --> 07:24.520 do the right thing, and put spaces instead of tabs, but it also will treat spaces as tabs, 07:24.520 --> 07:29.720 and if you press the back, because you've gone one too far, it'll probably take four spaces 07:29.720 --> 07:36.520 or wherever you've set your tab width to be, which is really annoying, so really what you want 07:36.520 --> 07:43.720 is to be able to hit enter and it align up, and a lot of languages, this is really easy, you know, 07:43.720 --> 07:51.960 think of JavaScript or something, it will, you tell you I'd say, hey, curly brace, indent one, 07:51.960 --> 07:59.560 and closed curly brace, the indent one level, but scheme, scheme looks a bit different to most 07:59.560 --> 08:06.760 languages, you know, and how does, how does it work? I think there might be more rules than this, 08:06.840 --> 08:14.440 but, you know, that you can see some of the examples of how indentation is supposed to work. 08:15.160 --> 08:20.760 Here I've got a procedure, and I've got one argument, and I could actually have more in the first line, 08:20.760 --> 08:26.440 and if I hit enter it will line it up perfectly, but if I actually just put the procedure call, 08:26.440 --> 08:32.040 and then hit enter, it will line it up with the procedure call, and then this is the one that I 08:32.040 --> 08:37.400 would not have known if I hadn't tested it in EMAX, you'll put an open parentheses in your press 08:37.400 --> 08:44.120 enter, and it will, it will indent one space to leave it. There's some special things that I think 08:44.120 --> 08:51.800 of us like body, they have a body, like defy, when you're defining a procedure, or once you're 08:51.800 --> 08:56.520 done with your bindings and the left lock or where and or unless there's a bunch of these, 08:56.680 --> 09:06.680 and these, you indent two spaces in, and so this is not something I can just tell like VS code, 09:06.680 --> 09:15.160 or they have like, do this. And so what did I, what was my first attempt of trying to get some 09:15.160 --> 09:20.840 of this to work in another editor, and this is going off screen, but this is, I just used EMAX 09:20.840 --> 09:32.440 for the indentation. And this is a save format that I set up, and it calls out to the script, 09:32.440 --> 09:39.240 and what's in this script. Oh, it's, it's requiring the scheme age mode, it's indenting the 09:39.240 --> 09:44.120 point, and then it's writing out to the files, so any time it hits save, well at least my PR's 09:44.120 --> 09:51.000 aren't going to get rejected, because my, my formatting is completely wrong. But this, this is 09:51.000 --> 09:57.960 actually not, not very good for many reasons, and not what people, we want to be recommending for 09:57.960 --> 10:06.440 people to do. So I spent a bit more time, and it decided to try and build a plugin for VS code, 10:06.440 --> 10:16.040 or VS codeium, the free version of this. And, you know, you can see it here, it's got syntax highlighting, 10:16.040 --> 10:21.880 as you might expect, and actually these rainbow parentheses come out of the box with VS code. 10:23.480 --> 10:31.080 And it, it does the indentation correctly. I, my plugin told VS code, hey, don't, don't bother 10:31.160 --> 10:38.040 with indentation. I'll, I'll humble that, and I build an abstract syntax tree of all of the 10:38.040 --> 10:43.720 SS expressions and their indentation levels, and then when you hit enter, it will walk back to 10:43.720 --> 10:49.480 tree and figure out where it should indentate to. Hopefully I'll have time to demo that. 10:50.760 --> 10:55.320 It has a few other things that E-mix didn't have, maybe you can configure it, I'm sure there's 10:55.400 --> 11:03.480 a, a minor mode for this, but I never remember these surface, a few of them, maybe. So, 11:03.480 --> 11:11.480 if you were on the, you know, the testing one, surface 64, but largely, I don't remember what any 11:11.480 --> 11:16.600 of these surface are. So, these, these comments are actually not in the source code. 11:17.400 --> 11:23.160 These are layered on top by the plugin. These don't appear in there. So, anytime you define these, 11:24.120 --> 11:29.240 surface, you can look at your code and, and the plugin will hopefully tell you what they are. 11:31.800 --> 11:37.160 But I also need to import these surface. So, it has this helpful surface picker as well. I can 11:37.160 --> 11:43.880 search, like, oh, I want the context bound one or whatever. And, and it will hopefully find 11:43.880 --> 11:51.240 the right one and can hit enter and it'll just put the import demo time. Let's see whether I can do this. 11:53.160 --> 12:00.120 So, I feel like demoing this is a little untyclimactic to, to E-mix users, because this will just 12:00.120 --> 12:09.640 look like how it should work. But, um, if we think about this, I've got, uh, use modules, and I can 12:10.520 --> 12:17.480 show the surface picker, and maybe want the, uh, cond expand, it's difficult to do and looking at 12:17.560 --> 12:25.320 screen, like, do that right? Oh, it's just off the screen, because it's so big. Um, I think it's 12:25.320 --> 12:36.680 like, on the X-Fat. Okay, uh, and I can, I can do this, you know, let binding. Um, I should just look 12:36.680 --> 12:42.120 up, you know, I can't wait, it's not mirrored. Um, and you can see, I'm hitting, I'm hitting enter, 12:43.080 --> 12:52.200 and it's indenting to the correct spot, um, and I can hit enter there, and it will indent to 12:52.200 --> 13:03.080 the correct spot here, too. Um, and, you know, I'm, uh, I'm, uh, sprightly developed, so I'm going to 13:03.160 --> 13:15.160 write a, uh, actor here. Uh, you can, you can, you can see, uh, I can, you know, you get the 13:15.160 --> 13:24.200 gist here, um, uh, I can't do this on the stage, but you can, you can see it's, it's indenting 13:24.200 --> 13:29.320 things to the, to the correct level, and we've got all the syntax highlighting, and this actually 13:29.400 --> 13:38.520 turns out to be a pretty, pretty, uh, needs, um, development environments, this huge, so, uh, 13:38.520 --> 13:43.960 I don't know if I can make this small, smaller, so it's slightly easier to see. Um, this is huge, 13:43.960 --> 13:50.760 but, uh, you know, like, it's, it's, like, highlighting everything and, um, handling all the indentation, 13:50.760 --> 13:56.680 and I've used this for over a year to write scheme code professionally, um, it seems to work 13:56.760 --> 14:02.920 pretty great, um, for, for what it can do. Um, so that was the demo that that's sort of where 14:02.920 --> 14:08.520 I've gotten to, there are a lot of holes, though, um, first I'm going to talk about other projects, 14:08.520 --> 14:15.000 and I think this list should be longer. I, I'm, don't know many of these. Um, the first is 14:15.000 --> 14:21.720 VS code has this, uh, language of a protocol, and I think a lot of other editor supports, I think, 14:21.720 --> 14:28.760 even e-max supports this, although, I don't know why you'd use this to scheme e-max. Um, I haven't, 14:28.760 --> 14:34.600 I haven't actually got this working, uh, so I, uh, I can't really recommend it, but I do think it's 14:34.600 --> 14:43.320 a cool project, um, and I do want to try and get this working. This, uh, supports a contextual 14:43.320 --> 14:49.880 auto-complete for your, uh, variables and procedures, and we'll give you documentation, and lots of 14:49.880 --> 14:57.320 the cool stuff that, you know, you might know if you use company or, uh, guys, uh, the guys are, uh, 14:57.320 --> 15:02.760 with the buffer and things. There are other VS code plugins, and I, I tried most of these before 15:02.760 --> 15:10.120 embarking on writing my own. Uh, most of these are just a syntax highlighting. Um, I did see an under 15:10.120 --> 15:17.960 you troopers talk, someone was using vim to write scheme. Uh, and so maybe, maybe the vim tooling is 15:18.040 --> 15:23.000 better. I used to be a vim user, but I haven't tested it. Um, someone on the sprite before him said 15:23.000 --> 15:28.680 they use the rainbow, delimitors, plug-in for vim, maybe there are some others. Uh, and like I said, 15:28.680 --> 15:34.760 I suspect this slide is missing a lot of cool projects. So if you know of them, uh, come tell me, 15:34.760 --> 15:42.840 I'm interested. Um, this is actually not related to scheme per se, but, um, I wanted to give 15:42.920 --> 15:49.240 it a shout out because it's such a cool project. Um, if anyone's familiar with market or I think it's 15:49.240 --> 15:59.320 pronounced magic for, um, e-max, this is a direct clone that works surprisingly well in VS code. Um, 15:59.320 --> 16:04.120 so, uh, that's something I found along the way, and I thought I would shout out because, um, it's 16:04.120 --> 16:12.760 very cool project. Um, so my plug-in solves the indentation, and we have this syntax highlighting 16:12.920 --> 16:19.640 but my plug-in brought that to. Um, I don't think I'm really the right person to implement 16:19.640 --> 16:27.880 paraded or smart friends because I don't use them in e-max myself. Um, um, and we don't have 16:27.880 --> 16:33.480 a ripple integration, but I actually think this is more doable. Um, it just needs a bit more time. 16:34.200 --> 16:40.600 Dave has been working on a huge ripple that you can connect over via a web socket, so I think that's, 16:41.240 --> 16:46.760 um, I actually don't think that would be too much work to integrate with this plug-in. Um, and the 16:46.760 --> 16:56.600 the documentation situation outside of e-max is, um, I would say pretty poor, um, I was meaning 16:56.600 --> 17:02.040 to move this slide so I'm going to come back to it. Um, so talk about the documentation a little 17:02.040 --> 17:08.040 more. This is, this is racket, which, another scheme, and I would say that it does this, I, 17:08.120 --> 17:13.560 I really like racket documentation. I think it, they, they do this really well. Uh, and so this is 17:13.560 --> 17:20.760 me searching for the string equals question mark, um, plug-in, and it has a search box on all 17:20.760 --> 17:28.840 manuals on the sidebar, uh, and then this is the search results. You can see, um, I can, I can find it 17:28.840 --> 17:35.640 in a bunch of modules, um, and when I jump to where I get the definition and then, uh, a bit longer 17:35.640 --> 17:43.400 and some examples, uh, really great. And I think this is maybe being a little harsh to the 17:43.400 --> 17:50.200 guy old manual, um, but usually when I try and use this in a web browser, I just open it and I know 17:50.200 --> 17:57.160 there is a procedure, uh, a page with a little procedures on in an index, but I typically will just 17:57.160 --> 18:03.080 control F and try and find what I'm looking for and hope that it is an in lots of examples throughout 18:03.160 --> 18:15.160 the manual. Um, and this, this web, um, UI that the, the info manuals generate, the web, um, 18:15.160 --> 18:21.480 is really not so great. And I think this is one place where we could get a lot of mileage, 18:21.480 --> 18:30.920 Gile has a module for pausing these, uh, info manual stuff and so we could, we could use Gile 18:31.000 --> 18:39.480 and just build a much better web UI with search, uh, and everything like that. Um, I think we could do 18:39.480 --> 18:44.680 a lot here. I, I don't think we should go away from the info manual system. It would create an 18:44.680 --> 18:49.800 e-max, uh, and it could work great on the web. We just need to put a bit more tool, uh, resources 18:49.800 --> 18:56.280 and tooling, you know, use some syntax highlighting on code examples, have a search. Um, there's a lot 18:56.360 --> 19:06.840 we could do here. Um, and then the slide I've put out of order, I'm sorry. Um, this is, I, I think 19:06.840 --> 19:11.400 of made things a bit better in this code, I hope you would agree. Um, there are, there are lots 19:11.400 --> 19:16.360 of other editors out there, lots of people using other editors. And I want people to be able to come 19:16.360 --> 19:22.680 to scheme, um, learn scheme and use the editor they want to use, and then be convinced 19:23.000 --> 19:28.120 that the team acts as great and switch to it. But I want people to switch to e-max because it's a great 19:28.120 --> 19:37.240 editor, not because it's the only viable path of writing scheme and the scheme programs. Um, 19:38.200 --> 19:44.760 there are books in the VS Code plugin. I, I am a bad spirit of this project. I sort of add what I 19:44.840 --> 19:54.040 need to get my job done. Um, and really I, uh, the motivation for this comes from one thing that's 19:54.040 --> 20:02.840 a big good options for, um, new people to scheme. I'm, I am at my heart, an e-max user. So, um, 20:03.480 --> 20:13.720 I, I think if people want to come and help out in my VS Code plugin, fix bugs, um, um, and 20:13.800 --> 20:20.280 help out there. That would be amazing. Um, add the ripple integration, both for, for the 20:20.280 --> 20:28.280 guy or VM, um, and maybe whoot, um, and help out with the documentation project. I think, uh, it 20:28.280 --> 20:35.720 will be, it'll be great if we get to a point where we don't have to recommend e-max as the first step 20:35.720 --> 20:43.080 of learning scheme. Um, so yep, this is just a call for help. I, I think if you're a scheme developer, 20:43.160 --> 20:50.360 if you, like any other editor, there is a lot to do here. Um, and so yeah, I guess I finished a 20:50.360 --> 20:55.400 little early. Um, are there any, uh, any questions? 21:04.040 --> 21:10.760 Andy? Just, uh, what do you, um, match, kind of, is it worth okay? Is it better than parer? 21:13.320 --> 21:25.000 With, with what's her? Yeah, my, my plugin does not handle. Oh, sorry, what do I do with the 21:25.000 --> 21:33.960 hash call on to come and out an entire S expression? Um, my plugin does not handle that at all, and that's 21:33.960 --> 21:42.600 actually a major source of annoyance because, um, we, we have some of those in the, um, 21:42.680 --> 21:49.080 spritly source code, and I will happily be reading this code and then get to the common symbol and be like, 21:49.080 --> 21:58.760 oh, that's, that's not great. Um, so, uh, I don't deal with that in short, um, and that's definitely 21:58.760 --> 22:07.640 one of the bugs. Uh, yep. So maybe this is maybe a bit of a meta question about, uh, so you're saying, 22:07.720 --> 22:12.440 okay, this person doesn't want to use e-mets. Um, use whatever editor you you want. 22:12.440 --> 22:18.680 And then you have a, as it looks right now, uh, told me a period of experience, and then maybe 22:18.680 --> 22:26.760 you think, oh, skin sucks because whatever, um, the experience is so inferior. Why? I don't just tell 22:26.760 --> 22:33.960 them, just use the real thing. Uh, so the question is, uh, if people use some of these other 22:34.040 --> 22:40.040 experiences and have a worse time, they might just think skin sucks. Why not just tell them to use 22:40.040 --> 22:46.360 e-mets and have a good experience? Um, it's a great question. And I think, uh, there are, there are 22:46.360 --> 22:51.720 two answers to this. One is, we should make e-mets easier to use. And there are lots of projects 22:51.720 --> 22:57.560 doing this, uh, you know, do e-mets and stuff trying to give you a better e-mets that is pretty 22:57.640 --> 23:03.000 configured, so we could recommend that. Um, but I, I think we're trying to solve that like, 23:03.000 --> 23:09.400 I think we can give people a good experience in editors that are familiar with. And so this is one 23:09.400 --> 23:17.400 stat, um, to make that happen. And then a call for help because I can't do this on my own. Um, 23:17.400 --> 23:24.280 I think we can make writing skin code in other editors a good experience. Maybe, maybe not as good 23:24.360 --> 23:31.480 as e-mets, but still a pretty reasonable experience where they can learn skin, um, write skin code 23:31.480 --> 23:38.920 professionally, even potentially, um, and maybe then be convinced of e-mets. For what it's worth, 23:38.920 --> 23:46.120 I don't think, um, writing and writing or the languages in a lot of other editors is as good as 23:46.120 --> 23:51.880 writing skin and e-mets. Uh, I think we have a superior experience than a lot of other languages. 23:52.840 --> 24:00.040 Uh, yeah. Um, I, well, does it generalize to other skins? So I saw you post-confielded like 24:00.040 --> 24:08.360 Kyle use modules for the skin is made up of that. Yes. Um, so I, I, I, I, I, oh, sorry, uh, I'll repeat 24:08.360 --> 24:14.520 the question. How well does the VS code plugin I wrote generalize to other schemes? Um, 24:15.400 --> 24:21.800 it both, it will do the indentation the same and you can actually configure which of the 24:21.800 --> 24:31.880 these like body clauses, um, it will do in the settings. Um, but I wrote the, this, the syntax highlighting 24:31.880 --> 24:38.360 and a lot of this with Gile in mind and I called the plugin, Gile scheme and then happens, I think. 24:40.360 --> 24:47.880 Um, and so really, it's aimed at Gile scheme. I think rocket scheme has some of the options here, 24:47.960 --> 24:55.160 other schemes. Um, I, I think another thing is that we could split the indentation part of this 24:55.160 --> 25:00.840 plugin out and then we could have that generally for other schemes and lists. Um, and if you're 25:00.840 --> 25:06.680 interested in doing that, I would happily accept a pull request and we can have two plugins, one for 25:06.680 --> 25:14.360 syntax highlighting and one for the indentation and the auto complete there, um, isn't very good. 25:14.440 --> 25:20.280 I think we need LSP or something like that and then you can get great contextual, aware, auto 25:20.280 --> 25:29.160 plate complete. Uh, yes. So true related questions. Sorry. Happy play with the VS code debugger at 25:29.160 --> 25:34.360 API. And the second one would be, do you also have a scheme development? Do you think the 25:34.360 --> 25:39.640 progress are useful or do you use in your databases compared to their reboot? This is something 25:39.640 --> 25:48.600 that you'll always hope in it. Um, so the question is, have I played with the VS code 25:48.600 --> 25:55.720 debugger API and how much do I use the boogas as a scheme developer? I have not played with it much. 25:55.720 --> 26:02.600 I think I read the docs a little bit for VS code plugins. Um, and I don't really use the boogas 26:02.680 --> 26:10.760 in scheme. I used to for C++ and some other languages. Um, I lean heavily on the P.K. 26:10.760 --> 26:18.760 P.K. P.K. P.K. I don't know if anyone else writes scheme in this way. So, I think the 26:18.760 --> 26:26.120 wrap-all and P.K. can do a lot of heavy lifting. Um, so, um, if people won't debug us, they can 26:26.200 --> 26:33.960 try and do that, but I don't think they're as necessary in scheme. Um, thank you. 26:33.960 --> 26:44.280 Thanks for watching.