Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
V
vscode-zil-language
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 24
    • Issues 24
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Jira
    • Jira
  • Merge Requests 0
    • Merge Requests 0
  • Operations
    • Operations
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • zilf
  • vscode-zil-language
  • Issues
  • #9

Closed
Open
Created Apr 01, 2019 by Jesse McGrew@jmcgrewOwner

[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.

  • Creating a language server using .NET
  • SDKs for the DAP

IntelliSense

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

Z-machine debugger

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

MDL debugger

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 metadata

  • Issue type: Epic
  • Priority: Medium
  • Fix versions: 0.3.0
Edited Sep 14, 2020 by Jesse McGrew
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None