import type { Expr, Pipeline } from "./ast.ts"; import { type GenerateCtx } from "./codegen.ts"; export declare function isPipelineAst(ast: Expr): boolean; type ContainerKind = "top" | "facet" | "lookup" | "unionWith"; /** * Compile a pipeline-shaped ArrayLiteral AST to an MQL pipeline (stage array). * * Caller must have verified `isPipelineAst(ast)` first; we still validate * every element here and throw a precise CodegenError on the first non-stage * element so the error message points at the offending position. * * Consecutive update op elements (`$.a = 1`, `delete $.x`) coalesce through * the same algorithm `jsmql()` uses at the top level — see * `generateUpdateOpGroups` in codegen.ts. Non-update op stages flush the * current update op buffer and emit its compiled $set/$unset stage(s) inline. * * `let` bindings extend a pipeline-scoped GenerateCtx that downstream stages * inherit; reshape-clearing stages drop the scope; a trailing `$unset` is * appended once if any let was declared. */ export declare function generatePipeline(ast: Expr, startCtx?: GenerateCtx): unknown[]; /** * Compile a `Pipeline` (a sequence of `;`-separated top-level statements) to * an MQL stage array. Each statement is lowered in isolation: a update op * chain (`,`-grouped, possibly RAW-split) goes through `generateUpdateFilter` * and contributes one or more `$set`/`$unset` stages; an expression must be a * stage call/object and contributes exactly one stage. * * Adjacent update op statements never coalesce — `;` is a hard boundary, in * contrast to `generatePipeline` (the `[…]` form), where consecutive * update op elements coalesce through `generateUpdateOpGroups`. This is the * core difference between the two pipeline forms. * * `let` declarations contribute one `$set` stage each and extend the let * scope visible to subsequent statements. */ export declare function generateImplicitPipeline(p: Pipeline, startCtx?: GenerateCtx, container?: ContainerKind): unknown[]; export {}; //# sourceMappingURL=pipeline.d.ts.map