 As some of you may have seen, I got the Stringer version 2.0 release done yesterday and everything uploaded, so yeah, that's a huge relief on my part. I've been working on that literally just that for like a month straight. And I'm glad to be done that and move on to something else. I have some stuff planned for the future with that, some stuff for a V2.1 and 2.2 release, but I'm going to give myself something else to do for a little bit before working on those features. I had mentioned in a previous video when talking about this and what my plans after getting this done, like what I'm using Stringer for, the pattern engine more than anything else, but the thing is a whole using it for other stuff. And one of these is a project called Langley, which is just another punny name for a grammar DSL, kind of like what you see with Antler or Yak or Bison, those various parser generators. And the idea is largely the same to provide that, but in an actual like integrated with the run time kind of way, and actually have it integrated entirely with the MS build system because there are hooks that they provide that you can do that. And any of you who have worked with any of those parser generators know what I'm talking about. The workflow gets a little weird because you have to build things separately and it's just, it's clunky. It's not like this project exists just for that point. Like I actually want to use Stringer as the engine behind it, which is why it's not exactly defined as like a Lexar or a parser or a tokenizer or any of those specific components. It's literally just a back end engine that can be used for that stuff, but it's like for Langley more than anything else. That being said, now that the 2.0 release is done, I will have a example, a tutorial on using it for validation because it still does those things. It just never actually generates a parse tree. And essentially Langley is the sort of domain specific language for defining the grammar and spitting out the parse tree that any .NET stuff can consume. I mentioned where I was going with all this. I had mentioned that some of this actually needs to be written in IL. And I'm not super happy about that, but that's just sort of the reality of it. Part of the reason why I am designing a specific DSL for this stuff is that working with language is not that easy, mostly because the tooling is really bad, not because working with language in and of itself is somehow really complicated. Some of the people who stick purely with theory, like if you learn that stuff in a purely academic environment, they will make it complicated, but that's more of an issue with just how academics approach things. Now it's not super practical. That was another thing. The default parser that Stringer uses isn't necessarily like a PEG grammar or an LRK grammar or anything like that. It's similar to PEG, and it might actually fit PEG quite well. But it was designed purely around, like, let's have actual source code examples, and can I parse the entirety of that? Yeah, it was designed much more practically, not around a specific parsing theory. But I need IL. And the reason for that is that especially in language stuff, you have multiple inheritance problems. You really do need multiple inheritance, and that's sort of a problem, because C-sharp doesn't support that, Visual Basic doesn't support that, and F-sharp doesn't support that. And some people would be quick to be like, oh, but interfaces are how you do multiple inheritance. To be correct, no. Interfaces are how you establish a contract in the interface to that type. It's not actually inheriting, it's implementing. This is an important distinction. With language stuff, you actually have a very serious need to inherit from two different types for semantic purposes. And going off interfaces really doesn't work that well. And while you can do it, you wind up with a very convoluted API where some stuff is inheriting directly from other classes, but then you also have interfaces and for calling certain members that have to be static because of what they are, like the parser for that token. Some of them are found in the class, whereas some of them you have to use the interface, but then you also have to provide a static class that has that in it, and you have to keep track of what's what and just it. The whole thing is immensely easier if you have multiple inheritance. And there's a pattern for properly doing this. You see that Java sort of has this worked out since they introduced. I don't know what they're calling it, but default method implementations for interfaces. C-Sharp has more recently introduced that as well. And there are other languages that implement it fairly well. I can't say C++ implements it particularly well. C++'s approach was important. It certainly led the way in actually doing it. In hindsight, mistakes were made at the time they were doing it the best they knew how. But it is what it is. Some people might be quick to point out that, oh, but C++ has a special managed runtime, and you can do that and no, you can't. It does for the .NET framework, but not for .NET Core. So that's a problem, obviously, since .NET Core is very obviously the way forward. Maybe Microsoft will port that over, but for the time being it's just simply not there. And it would be... Bizarrely, it would actually be easier to write some of this in IL than in C++ because C++ has a lot of funky stuff going on, and I don't need that. I don't need very strict control over how the memory is managed and exactly how pointers work and all that. I literally just need the multiple inheritance and a little something special with exactly how and where methods are defined, but overwhelmingly it's just needing multiple inheritance. Yeah, I don't need all the C++ fuckery, different projects maybe, but not for this. So there is two extensions already out there that exist for working with IL, and both of them have their problems, and I'll cover that. The one I had mentioned was IL Support, and IL Support is... What it tries to do, we figured out, just really isn't going to be maintainable long-term. This is unfortunate. Maybe the guy... Jean-Philippe, I believe it was a while ago, since I last interacted with him, and I'm not good with remembering names, but I think it was Jean-Philippe, but it's Insomniac on GitHub. He's the author. And what IL Support did was intermix the two. So you'd have a, say, like C-sharp project, but the special IL Support C-sharp project would allow you to have IL files in there as well, and it would compile the two together. But it did this through a little bit of trickery, and it seems like going forward, it's just not going to be that maintainable. The other one is IL Proge or something, and I don't remember what the name is for that at all. The issue there is that it doesn't have any syntax highlighting, which is particularly annoying, and as you'd expect then, it also doesn't have any IntelliSense, which IL Support does offer both. Which is good. It also, there are a number of issues, they're aware of them, it's all over the readme. So I got to figure out before I can really move forward. Am I going to basically just hand write and hand compile the, well not hand compile, but make like a build script for doing the IL and then import that into an actual like C-sharp or VB project that does the rest. It works, but that's clunky, and makes it considerably harder for people to contribute to. Also means that I don't have any highlighting for IL nor IntelliSense. The IL Support's approach is ideal, but we've, that thread in the issue that I had brought up that something wasn't quite working. We went very in-depth into trying to find a solution and it's not looking good. Plus, he seems to have other responsibilities and can't contribute much to it, at least based on how many contributions have been happening recently. Although that may also just be because he doesn't himself think that it's very maintainable going forwards. So the other option that I have been considering and it's something I've really got to sort of do anyways, going forward it would be good to familiarize myself with the LSP, the Language Server Protocol. This is because if you implement an analyzer that also can communicate over the LSP, you have an analyzer that can work with basically any tooling that implements the other side of the LSP. That's really important and sort of abstract, but basically if you have in this example an LSP for IL, any editor that supports, that implements the LSP client side, I think it is, can get information from that LSP, from that language server. So things like syntax highlighting. You implement the classifier in that LSP compliant analyzer, Visual Studio Code, Visual Studio, Eclipse, I think JetBrains, Vim, and Adam, plenty of others just get syntax highlighting. You implement the IntelliSense side of that and all of those and everything else that supports it just gets IntelliSense. That's extremely, extremely useful. So it would be good to familiarize myself with that and obviously since IL isn't a particularly sophisticated language, it's basically just assembly, like it's assembly. It does not have a complex grammar at all. That would be really the ideal sort of project to familiarize myself with the LSP. And then once that's been implemented, it's literally just dealing with the how do you get ILASM and ILDASM for the specific platform that you need to work with. And that's a little bit trickier, but there are ways around that and yeah. So I'm leaning towards implementing that, which is definitely a few months long project. I really prefer it. It just existed. Microsoft, this has been your thing for a while. Why is there no project support? Why is there no editor integration? I get that you don't mean for people to be programming in it, but it has to happen sometimes. Please, why did you not do this? Yeah, it might be worth it. It definitely seems to be worth it to do that. Even if it's just a learning exercise to get familiar with how to write the LSP and how to integrate that with at least a few editors. Yeah. That's really all I got to say for that. You're probably going to be seeing an ILLSP soon-ish. Also, look forward to December 17th of this year, so 2019. I'm part of the F-Sharp Advent this year. For those unfamiliar with this concept, because I know most viewers of this channel are still primarily EIDA programmers, or at least people interested in EIDA, which doesn't do this, because they're basically just like, fuck the community. Certain programming communities do an Advent calendar kind of deal centered around the programming language that the community is built around. So, like I said, I got mine in the F-Sharp one, which I know I don't dabble too much with, but I do know some neat stuff about F-Sharp. You'll have to wait to see what the topic is about. Every day, just like you would do with a normal Advent calendar, you get these articles that get published, and the managers of the event make sure that they get spread around pretty well, so there's good visibility. But, yep, mine's the 17th. So, look forward to that. I'll have an announcement on here, obviously, enough, but yeah, I'm happy about that, because it's good recognition. And since we're on that subject anyways, I've actually been talking a little bit with a project manager. I'm not going to say who or what not, but a project manager at Microsoft, because they're quite impressed with the performance I've been getting out of Stringer, and they're sort of talking about whether or not certain things that I did would be applicable to their Regex engine and shit like that. So, really nice to see recognition. This is what I was talking about in previous videos, that a big part of why I'm really not doing added development anymore is because despite doing impressive stuff, I've been met with hostility from them, but welcome recognition from the other side. When these go in tandem for enough years, do you want to contribute to a community that's hostile to you? Nah, cool shit. Actually really heartwarming to get recognized like that. So, it's cool shit. Until whatever I don't know what I really got in the video pipeline. I'll try to have that tutorial done soon. The next day or two should be because it's basically implemented. I just got to do the video. Until then, have a good one.