If we could work out some minimal, core functionality, we could start working on the compiler architecture. I believe that a very small set of features should be sufficient. After that we could just fork the compiler to see if we like a feature or not, slowly building up the base language (this is sort of how Rust does it, but way smaller scale).
End goal
A minimal set of language features that are here to stay (doesn't have to stay syntactically, but semantically shouldn't change too much)
A compiler that manages to produce an executable/DLL/NuGet package
A VS Code language server that gives basic support, like error reporting and go-to definition (with LSP)
(Questionable, I've never done this before) A decent debugger, also for VS Code (with DAP)
Language features
I'm thinking of implementing the bare minimum.
A few primitive types
32 bit integer
a void-type (maybe call it unit and have it be a zero-sized value?)
No namespaces, visibility, classes, ... This is really about connecting up major components of the compiler. This is little enough that - if needed - we can just tear it out and reimplement almost everything without hurting the architecture. Again, this is so minimal , that syntax shouldn't matter yet.
Compiler
The focus should be the architecture. Again, the features are so minimal that those almost don't even matter. The compiler should follow a query-based architecture. More on the query-based compilers here and here.
We should also lay out the proper error handling method, not throwing on the first error. It is really hard to tear out a "stop-at-first-error" design, once it's been established. The one described in the Salsa video is good enough and should work.
The queries should be designed in a way that makes implementing the basic Language Server implementation simple.
The compiler should be asynchronous and allow passing in a cancellation token from day one. This is very important for tooling.
Language Server
The OmniSharp project has an LSP implementation, we can piggyback on that. The Language Server should:
Report compiler errors
Have go-to definition support
Tell the type of a symbol on hover
Debugger
Again, I'm unsure about how a debugger should look for a .NET language, I'm really inexperienced with writing debuggers. I'd be really happy, if we could write a Debug Adapter (again, OmniSharp has the protocol implemented) and have:
If we could work out some minimal, core functionality, we could start working on the compiler architecture. I believe that a very small set of features should be sufficient. After that we could just fork the compiler to see if we like a feature or not, slowly building up the base language (this is sort of how Rust does it, but way smaller scale).
End goal
Language features
I'm thinking of implementing the bare minimum.
No namespaces, visibility, classes, ... This is really about connecting up major components of the compiler. This is little enough that - if needed - we can just tear it out and reimplement almost everything without hurting the architecture. Again, this is so minimal , that syntax shouldn't matter yet.
Compiler
The focus should be the architecture. Again, the features are so minimal that those almost don't even matter. The compiler should follow a query-based architecture. More on the query-based compilers here and here.
We should also lay out the proper error handling method, not throwing on the first error. It is really hard to tear out a "stop-at-first-error" design, once it's been established. The one described in the Salsa video is good enough and should work.
The queries should be designed in a way that makes implementing the basic Language Server implementation simple.
The compiler should be asynchronous and allow passing in a cancellation token from day one. This is very important for tooling.
Language Server
The OmniSharp project has an LSP implementation, we can piggyback on that. The Language Server should:
Debugger
Again, I'm unsure about how a debugger should look for a .NET language, I'm really inexperienced with writing debuggers. I'd be really happy, if we could write a Debug Adapter (again, OmniSharp has the protocol implemented) and have: