 So I'm going to be talking about some recent developments in Askeli tooling, particularly editor tooling and documentation generation and so on. So Askeli ID Engine was a project started in 2015. It's supposed to provide a consolidation of effort of all the different people working on Askeli editor tooling and things like that. And also provides a uniform way for editors to talk to programs that provide intelligence about Askeli source. And also it aims to provide a sensible framework. So if you want to write your own tools that provide information about Haskeli source, it's easy to integrate it into editors and already existing workflows. So brief history in 2015, Alan Zimmerman and some other people started this thing. But then they tried to build their own protocol for editors to communicate to Haskeli ID Engine, which kind of fizzled out and things didn't really work out. So in 2016, 17, Microsoft came up with this thing called the Language Server Protocol, which provides a uniform back end protocol so that editors can talk to code intelligence tooling. And this is cross language. So how the protocol basically works is you have all these languages on one side and all these editors on the other side. So if you want to use JavaScript auto-completion or diagnostics or things like that in WIM, you need to write a JavaScript plugin in WIM, another for Atom, another for VS Code, another for Emacs, and across all editors. So there are basically for each language there has to be a plugin for each editor. So what the Language Server Protocol does is it provides a standardized set of features that your tooling can provide. And all the editors just have to write a plugin that can understand this protocol. And your language server will work with all the editors that have a language server plugin. So this provides, this turns an m cross n problem into an n plus m problem. So instead of writing n cross m different tools, you just write the people who know about tooling can write tooling and people who know about editors in writing editor plugins, they can write their editor plugins and it will all work together. So I don't think we'll have time for questions in the end. So if you have questions, just raise your hand and I'll try to answer them. So in June 2017, I started an Etsoc project to add LSP to HIE and that went pretty well and HIE greatly gains lots of traction and this year also there was another GSOC project working on HIE and by Luke Lau and he also extended it quite a bit. So it has all these features. You can go to definition, find references, completion. I'll just show you an example. This is HIE running in VS code and this VS code is stalking via a plugin to the HIE executable. The HIE executable will work across any editor you want. If you have some other editor like Emacs or WM or whatever, as long as you have an LSP plugin and you can tell it where to find the HIE executable, it'll give you all these features in your favorite editor. So for example, on hovering we have documentation and this comes from HEDOC and you can click on stuff and it'll open it up in line. Exactly the documentation page. You can, this is exactly the documentation for your project. So you don't have to worry about versions and stuff. HIE handles all of that for you. You can also look at the source of stuff. So the source of from list with is opened up. You can, when you click on stuff, it'll highlight users. So this, if you wanna find out where this access is defined or used, it highlights where it's used in this color and in another color it highlights where it's defined. So this works with any kind of symbol in your project. So it also has things like auto-completion and quick fixes. Let's say I, this is actually a code for HOOGLE which is another Haskell tool which is also integrated into HIE. So if I say foo equals port str hello world. So this bracket is redundant. So HOOGLE, yeah. So I get a warning here redundant bracket and hopefully somehow it should have popped up here. So I can do these kinds of code transformations and stuff. I can, map is imported here. So if I want to see what function map defines, what functions are exported by map, I just type map dot and I have all the functions in the map module with the documentation, the type and so on. This is basically an intro to HIE. You can look at the GitHub for more features that we support. And this is a cross editor. So it should work with your favorite editor as long as it implements, it has a plugin for the LSP protocol. So we use GHCM, how many people use GHCM? Have used GHCM on here. Yeah, and so GHCM has two parts. Now it's being split into two parts. One is the executable which used to be what you use to interact with GHCM and there's GHCM of the library which sets up the GHC session for us. There's also all the dependencies and where to find them and just hands higher working GHC session so HIE can talk to GHC and give you all your features. So HIE also has a extensible plugin architecture. It's pretty easy to write plugins if you want to hook into already existing functionality if you wanna provide more quick fixes or more kinds of diagnostics. Over here we have two kinds of diagnostics right now, diagnostics from H-Lint which provides general linting and we also have regular GHC diagnostics. So if I say four equals one plus A, it'll give me a type error. Yeah, it says no instance for num car. Car isn't a number so that kind of stuff. And even if your code doesn't, this code doesn't compile but even then if I hover over this stuff I still have all the features. So even in this version of the code that is not compiling, I remember the last version of the code that compiled and tries to use information from that to give you information about all your code right now. So it's still functioning pretty well, it's not broken even though this code isn't compiled. It also correlates positions in your new document so if I write some gibberish here, you'll notice that over here I still, even though that line shifted, I still get the correct documentation for this symbol here. Because I keep track of how the changes come in and whether this thing is actually in the old document and how the positions correlate and it'll give you the information from the old version of document that actually did compile. So this is an overview of how it works. This is the client which is VS code. When you type something, it sends a document, did change notification to high. High processes that updates its view what it knows your code to be and it invokes all the plugins, the generate diagnostics and so on. It returns those and then the client gives you, asks for more stuff if you click on something or if you want to go to a definition and so on. If you want to go to the right names definition. If you want to, you can navigate and you can just control click and you'll jump to the definition of wherever the thing is defined and so on. These kind of features, these are, the client makes a request. I want to know the definition of symbol at dislocation and high tries to figure it out and respond. So this is basically the workflow between the editor and high. And writing high plug-in is pretty simple. You just have to populate this kind of data structure where you provide your plug-in name and description and stuff like that. And if you want to provide, if you want to hook into existing features like you want to provide code actions like the removing the bracket thing and stuff like that, you can add one something here and it will automatically surface those when the user clicks on those. If you want to provide more kinds of diagnostics more information when people hover on a symbol, so on. So that kind of stuff, you can easily extend it. Alan Zimmerman recently gave a talk at Haskell Exchange if you want to know more about writing plug-ins for high and stuff. So that he delivered into more details and how you can do that. So this summer I worked on a project on getting GSE to output something called .hie files. If you compiled Haskell, you know that GSE generates .hie files from your source which contain information about your code and so that GSE can resolve it. So the problem is how many of you have used Hadock? Yeah, so when you use Hadock and you enable when you say enable documentation equals true or whatever and you try to compile your code while in your workflow, on your project if you enable documentation or you'll see cabal or stack or whatever you say building your project, then building documentation and it basically you'll notice that it doubles your compile times pretty much because Hadock needs to compile all your source all over again just to know about what GSE already knows about. When GSE compiles your source it resolves all the names it knows the types of everything and it knows where the docs are and so on but Hadock needs to repeat all that work just so it can generate docs for you and it basically doubles your compile time. So what HIE files allow is allow for tooling all the information that GSE collects while it's compiling the code if you enable an option called F write HIE that has just been merged into GSE head a few days ago so you'll see it in GSE 8.8 hopefully. So if you enable that option you'll see a new file next to your HIE files called .hie files. So these contain different kinds of information about your source so that tooling can read that instead of asking GSE to compile everything once more so that it can tell you about your port. So and even if you have dependencies and so on HIE currently cannot give you cannot tell you where this from integral for example is being used in your dependencies and so on. So what HIE files will allow you to do is scan all your dependency tree for .hie files you can collate all your dependencies together and present you okay this function is being used in all of these places and that that is future work that remains to be done but it's quite possible using HIE files. You don't need to invoke GSE on anything you just need to read the HIE file and it can generate all that stuff for you. So this is a stuff that is available in HIE files we have a resolved name so all it resolves all the names so that name shadowing and if you have name two names that are the same but they're not actually the they look the same but they're not actually the same all that resolving is done by GSE it has to do that to compile your code so all that it puts into HIE files which name might be actually mean when you say map is it map from set is it map from list so on and the type of all sub expression and expression in your source that is also available and the types of every identifying your source and also we try to calculate scope information anytime symbol is defined we try to calculate exactly the precise scope where in your text is this symbol in scope so that can be useful for things like completion like you can know exactly which functions are or which symbols are in scope at a particular point in your source you can get smart completion that takes into account local definitions and local declarations and so on so and it also includes the original source so let's say you work on something and it doesn't compile and then you close HIE or whatever you close your editor and you come back to it another day now code doesn't compile so when HIE ask GSE to give it info about this code GSE will say I can't do anything that your code doesn't compile I can't tell you anything about the code because it doesn't compile but if you have a HIE file on your system from the time it last compiled tooling can make use of that HIE file to still give you information about your source so I have extended the hyperlink source have if you've ever used Hadock with type information so this is doc's hyperlink source for GSE so if I hover over something you'll see I get the type right there so this is all generated from HIE files and now this summer another person Simon Jacobi worked on a project called HiHadock which puts all these doc strings into .hi files so to generate all of your Hadock docs both hyperlink source and the doc page you don't need to invoke GSE again all the information required is in your .hi files and .hi files so that makes it a lot faster and less bug prone like that still hasn't been implemented but it's now possible so in by 8.8 you should hopefully see these features so now if you see if I hover over say something with a parameter with a polymorphic type it'll give me both the types of the specialized type how you're using it at this position and also the type, the generic type the actual type of new IOL app which is the polymorphic type so you get to see both the original type and the specialized instantiation at this point and we also like this IXA if I highlight this is not really visible I think but if I hover over a variable it's all highlighted and precisely those it's not text-based highlighting like if you have four three places in your source code but they're different foos it'll not highlight all of them it'll highlight precisely the foo which is in the same equivalence class as the variable you are hovering over so that kind of stuff this HIE files contain a lot more info and I don't really know JavaScript and so on so if anyone has any ideas on how to put scope information and references data in these hyperlink source files please contact me or we can improve this a lot so we're not taking all advantage of all the information in HIE files to generate hyperlink source but it's possible and so in the future we hope to see integration of HIE files in different tools like Hadock there's already a pull request open which should be merged pretty soon and also Haskell ID engine will should I'll try to be extended to take advantage of that HIE files if you're interested in helping out in any of this like contribution of welcome V generally if you're on IRC on free node the Haskell ID engine if you want to help out you can just sign on there and ask Alan or me or Lucla or someone about what you can do to help and the GHC mode is the front end is dying is being retired and it'll become a library Daniel Grover the person who's maintaining GHC mode he's rewriting it so that we become a lot more reliable and support new build and we do support we have some limited extent of support for new build projects in Haskell ID engine but it's still kind of iffy because it keeps changing and new build is still under development so it keeps changing and so on so it's not that reliable so GHC mode is being rewritten to use source plugins I believe so that all of the issues with build different build tools, kabas, techniques all of them can be resolved so that that's a work in progress Alan is working on incremental compilation which is as you're typing GHC will try to compile as much as it can even if your code has an error or something you just tab out those portions so that if you wanna if you're interested in that talk to Alan again he's there on Haskell ID Haskell ID engine if you wanna speak to him and recently a few weeks ago there's been a new development called the language server index format which is made by the LSP guys which is basically a file LSI of.json that lives in your work tree that contains cached information about all the LSP requests and so on so it's mostly useful for dependencies and things that don't change that much static files so instead if you look over here I don't have I can't jump to the definition of this because HIE because the source may not even be available right now because when stack or whatever builds say byte string it doesn't keep the source around for HIE to be able to access it and show you the definition and so on or even if you I want to use where is this bs.length function used in all my dependencies that is not possible right now but HIE files and language server index format is basically a way to solve that it contains information about all your source tree including dependencies and all in a single file so plugins can directly read that file instead of going through a language server like Haskell ID engine so you don't need to have any executable running so memory issues are solved you just read that file and you get all this information about your source so that would be useful for dependencies and so on and it should be a very easy task to translate the information in HIE files to this language server index format because they contain mostly the same kinds of information so these are a few links to if you want to install or try out HIE you can check it out here this is the language server protocol and discuss other is there time for questions