Skip to main content

Module extract

Module extract 

Source
Expand description

Range-selected function extraction.

Every other semantic edit selects a named thing — a symbol row, a heading, an ast-grep pattern — and rewrites at or around it. An extraction selects a run of sibling statements that has no name, no symbol row, and no single AST node, and produces two edits that must agree with each other: a new function whose signature is derived from the selection, and a call whose arguments come from the same derivation.

That second property is why this module refuses so much. A rename that misses an occurrence breaks the build loudly. An extraction with a wrong parameter list can compile and silently change behaviour — a name that should have been a parameter falling through to a module-level binding of the same name is the exact case, which is why module scope is classified explicitly below rather than left to “not bound in the enclosing function”.

The derivation itself is language-general; what is not is the vocabulary it reads (which node kinds bind, read, block, and escape) and the spelling it emits. Those two live in [Dialect] and the emitters at the bottom of this file, so a language joins the untyped family by naming its node kinds rather than by growing a second copy of the analysis. The family is exactly the set of languages whose signature is derivable without type information: Python, GDScript, and the JS-like grammars. TypeScript is in it only because it can copy an annotation it already has — where it cannot, it refuses rather than writing unknown or an implicit any.

Structs§

ExtractionPlan
A derived extraction, ready to be spelled by a language emitter.

Enums§

ExtractionRefusal
Why an extraction was refused.

Functions§

plan_extraction
Derive an extraction for the statements covered by start_line..=end_line (zero-based, inclusive).
render_extraction
Render an extraction: the new function and the call that replaces the range, both already indented for their positions.