KCL priorities

[nrc]

Input from other teams

P1 things are things we intend to work on in the near future (i.e., in the next quarter or two). P2 are postponed until after the P1 issues, but small items might get done if there is significant requests. P3 are things we think are important but don't have the resources to tackle in the foreseeable future.

The high-level strategy is to focus on implementing constraints and refactoring to move code mods and anything aware of the interpreter implementation to Rust (and kept behind stronger APIs). I've prioritised quite aggressively to make sure we can tackle these, but they're still very large items of work. They will take time and we'll deliver incrementally to reduce risk.

Open questions:

We would like input from others to answer these questions:

• do we need to put significant effort into improving the editor experience soon?
• are there other features/work which can help Text-to-CAD? This is a priority for the company and a short-term focus for the team, but we're not sure if there are bigger work items which should be prioritised for this.

Features

P1

• Constraints (XXXL) *
  • Includes construction geometry
  • Sketch Mode Revamp #7435
  • Touches on tags, caching, and more
• Versioning, experimental features, back compat policy (S)

P1.5: Libraries (L), we'll prioritise constraints over libraries, but fit in libraries work where we can and be ready to make it P1 if there is motivation

P2

• if let or whatever for handling optional types (M)

• varargs and splats
• Logging (S)
• incremental output (output appears as execution happens)

P3

• Tags (XL, back compat?)
• Function functionality (L)
• Interfaces, enums, more types stuff (L)
  • Enums in particular might be more urgent, using string constants is causing friction
• Vector and matrix math (L)
• Loops and other control flow (M)
  • Question: possibly bump priority since it addresses friction around the accumular argument of the function argument in reduce, which is causing some issues for people and AI
• More shape functions (rectangle, polygon, sphere, etc) (M-L)
  • Shape helpers for MechEs, coders and LLMs #7508
  • Maybe includes frontend understanding and editing through function calls, if not we should do this in any case at some point

Polishing

P1

• General bug fixing
• Units (S/M)

P2

• Editing experience
  • Improvements to autocomplete
  • More 'on hover' information
  • Big question about scope/scale is whether we need significant changes to CodeMirror editor
• Performance
  • Improved caching (per-module or finer-grained caching) (L)
  • Finish client-side id generation - unknown numbers of ids for edges (other ways of referring to edges than ids) (module-scoped ids?)
    • Facilitates better batching
  • Program memory improvements (L)
• Modules and semantics (L, back compat?) (needs references)

P3

• Docs (M)
• Recursion (S)
• Argument names and other improvements to std (M, back compat)
  • Tracking: possible improvement to std lib naming and layout #6937

Refactoring

P1

• Frontend API (move codemods to Rust, don't expose AST, etc.) (XXL)
  • design API (cover extrude etc, current sketch functions, future constraints)
    • mock exec, formatting, node paths, artefact graph, edits via feature tree
    • where else are interpreter internals exposed to TS?
  • port TS to Rust and implement API for non-sketch functions
  • do we need to change the state handling? E.g., making interpreter a service rather than stop/start?
  • do we need/want to change the AST to do this?
• Worker thread stuff/sharing state between LSP and interpreter (better IDE experience) (M)

Worker thread stuff might be P2, depending on resources, and prioritisation of editor experience.

P2

• References in memory (perf, tags, semantics) (L)
• Tests (time to run, duplication/out of date tests, two kinds of simulation test) (M)

P3

All these changes require the frontend API refactoring

• Redo parser (better errors, incrementality, keep on trucking) (XL)
• Static checking (IDE features, errors, AI) (XL)
  • given that this is probably useful for TTC (a better alternative to 'mock execution') we might want to prioritise this work, however, given the scale of the work, the dependency on another big refactoring, and our other priorities, we'd either need to drop something currently prioritised or have more resources
• Interpreter representation (i.e., moving to a more VM-like arch) (perf, caching) (XL)

[nrc]

Originally posted as a gist, posting here for more visibility and wider discussion