The different kinds of KCL execution.
- **Engine Execution:** AKA (plain old) execution, real execution. Uses a real engine. This is exactly what you'd expect from normal execution if you don't think about it too much. KCL code is executed locally, and stdlib functions send messages via WebSocket to the engine. The engine is typically on a remote server.
- **Mock execution:** AKA engineless execution. Similar to engine execution, but no connection is made to an engine. The engine interface/trait is implemented with a no-op. There can be no legitimate engine responses to queries, so anything that relies on an engine query is undefined behavior. Sometimes the interpreter generates a fake answer like 0. Other times it generates an error. We don't test this, and developers generally don't think about this use case as something that needs to be correct in any meaningful way.
- Despite all this, both TypeScript code in ZDS and Python code in Zookeeper use mock execution as a way to validate code in various scenarios because it's a lot faster than engine execution and we don't currently support static checking. Validating arguments is an example of something that can currently only be done at runtime.
- **Partial Execution:** In ZDS sketch mode, TypeScript code extracts only the KCL pipeline of the sketch from the KCL AST. It's limited to the syntactic structure of the pipeline. Only that subtree of the AST is executed using mock execution. KCL code that is generated by ZDS's UI is the subset of KCL that is well-defined and expected to work during mock execution. Since the interpreter is given only a part of the full program's AST, it relies on previous KCL memory being cached so that variable references continue to work.
- **Sketch Mode Execution:** This is new with sketch-solve. From a high level, it is similar to partial execution, but the full AST is present, meaning that source ranges and paths to AST nodes are unchanged. It's also intended to be used with sketch blocks, not sketch v1 pipelines, so it has different syntactic limitations. Another critical difference from partial execution is that when code attempts to send a message to the engine, instead of returning bogus answers, it's defined to be an error. Sketch mode execution is forbidden to contact the engine, regardless of the engine implementation.
- In ZDS sketch mode, Rust code in the `frontend` Rust module parses the full KCL code, finds the sketch block AST node, marks the node it wants to execute, and mock executes. Arguments tell the executor that it's in sketch mode. When it's executing, it skips over items until it reaches the marked sketch block. This also depends on the previous memory cache. After executing the sketch block, it exits early.
- The API currently relies on Object IDs generated from engine execution in order to find the AST node in the first place. If the sketch block can be identified another way, this limitation could be lifted.
- But we still need the previous memory cached anyway for things like planes and faces that need the engine to be created. We can't communicate with the engine in sketch mode.