Juniper
Juniper copied to clipboard
Error tolerant Parsing and Type Checking to improve editor support
Hello!
The language looks awesome! I just started using it but I didn't find editor support except for syntax highlighting, so I started to create a Language Server Protocol implementation and a VS Code extension which you can check out in my fork of this repo. I think it already gives a pretty nice basic programming experience :)
So far I've tried to make as little modification to the original compiler as possible but I think I've more or less exhausted the LSP features that can be implemented this way. If you like these changes I made to the compiler, I can create a PR.
In order to support more LSP features for the language (completion suggestions in lots of places, semantic highlighting, types on hover, go to definition, etc...) there's a need for a more error tolerant parser and a type checker that can report multiple errors at once or give incomplete (but useful) information on a file that has syntax or type errors. Stretch goal could be some kind of incremental parsing/type checking.
I'm happy to already start working on extending the parser and the type checker this way. I'm planning to make changes including but probably not limited to:
- Parser that records all text and positions in the AST (even keywords, comments, etc, useful for semantic highlighting)
- Parser that recovers from syntax errors that happen typically when you type new code.
- Type checker that can work with an AST that contains parse errors.
- Type checker that never or rarely throws an exception (therefore records type errors in some other way)
- Type checker that can output multiple constraint errors instead of throwing on the first one.
- Type checker that keeps track of type variables' and capacity variables' original names (for more readable type strings)
- (?) Type checker that can use the results of the last type check, and only recheck the AST that has changed
- General refactoring, e.g. to reduce warnings in the code, or adding strong aliases e.g.
type ModuleName = ModuleName of string
- ... I know I must be already forgetting something
Any change/progress I make I would be happy to push back to this repo, but I'm not confident that it's useful for you to accept the changes. Ideally, nothing I do will change e.g. the typing rules (*for well typed programs anyway) but the details of the actual implementation could differ greatly. Maybe it's important that you're closely familiar with the codebase in case you need to work on a new version or a new paper, so a big change would cause difficulties in these areas. On the other hand, if you accept the changes and implement any future modifications on top of them, then the improvements would be instantly available to the Language Server implementation and any editor extensions. I'd ask you to share your viewpoint on this.
So in summary, I'd like to extend the parser and the type checker in order to implement more Language Server Protocol features for an enhanced editing experience of Juniper source code. Or that's my plan anyway, which I'm not sure exactly how far will get in reality.
I'd like to hear your thoughts on the topic generally, and on the possible joint future of the original compiler and the LSP version. Thanks in advance!