[VZP-9] Port language and debug features to C# and integrate with compiler and interpreter
zil-language currently implements major functionality in TypeScript. We could avoid redundant effort, make the editor experience more consistent with how ZILF actually works, and ease development by implementing them in C# instead.
The extension currently uses its own lexer, AST, etc. to understand ZIL code, running inside the vscode extension host. To provide assistance with built-in functions, it relies on data exported by ZILF.
We could move this to a LSP implementation that uses the existing functionality in ZILF instead. Without evaluating any MDL code or compiling the project, we could:
- Use ZILF's parser (with
%-macros neutered) to detect syntax errors and build a document AST
- Use AST-based scanning to provide a passable subset of document/project symbols
- Use AST-based scanning to identify call site context
- Provide signatures based on actual SUBR and ZBuiltin definitions
If we don't mind invoking ZILF's interpreter and compiler, we could also:
- Provide full diagnostics while editing
- Provide expansions when hovering over macro calls
- Use MDL and ZEnv context to provide a full, accurate set of document/project symbols
- Show the generated ZAP code for a routine
- Link to included library files
If we don't mind invoking ZAPF too, we could also:
- Generate abbreviations in the background
The extension currently uses a Node-based adapter, essentially wrapping ZLR's command-line debugger with a simple network protocol.
If we implemented the Debug Adapter Protocol in C# and integrated with ZLR, we could:
- Simplify the communication between the extension and the interpreter
If we also integrated the debug adapter with the ZILF language service above, we could:
- Evaluate full ZIL expressions for watches, hovers, and the debug console
- Provide completions for expression entry
- Use PROPSPECs to format property values (e.g. make exit properties readable)
- Use knowledge of the compiler output to format values in general (e.g. detecting string and routine addresses)
- Provide an accurate set of scopes
- Show the source code after macro expansion instead of attributing the expanded code to the MDL code that expanded it
- Support live routine editing:
- ZILF verifies that the change won't invalidate the RAM state and generates ZAP code for the routine
- We append the new code to the original ZAP output and assemble new Z-code for the routine
- ZLR installs the new Z-code in ROM, patches the original routines to jump to it, and updates the instruction pointer
There's currently no support for MDL (compile-time) debugging.
If we implemented the Debug Adapter Protocol in C# and integrated with ZILF, we could support that, although it'd take some restructuring to make the interpreter steppable.
- Issue type: Epic
- Priority: Medium
- Fix versions: 0.3.0