Support linear composition (`NEXT`) to chain statements in a single query

[matiastoro]

What is missing

There is no way to chain statements. All of these fail in the parser:

MATCH (n:Interseccion) RETURN n.osmid AS id
NEXT MATCH (m:Interseccion {osmid: id}) RETURN m.lat AS lat
-- ValueError: unexpected token Name("NEXT") at position 12

MATCH (n:Interseccion) WITH n.lat AS x RETURN x LIMIT 3
-- ValueError: unexpected token Name("WITH") at position 6

LET x = 1 RETURN x
-- ValueError: expected path pattern, got Name("LET")

MATCH (n:Interseccion) FILTER n.lat > -33.45 RETURN n.osmid AS id
-- ValueError: unexpected token Name("FILTER") at position 6

The ISO form is NEXT (linear composition), not Cypher's WITH — worth implementing that one, and it is the coherent choice given the rest of the engine follows ISO.

Why it matters

Any two-stage query splits into two round-trips with string interpolation in between. The concrete case: "the nearest corner to this point, and from there the route to that one."

-- today: two execute() calls, with the first result pasted by hand into the second
MATCH (n:Interseccion)
WHERE n.lat > -33.4503 AND n.lat < -33.4403
RETURN n.osmid AS id
ORDER BY (n.lat + 33.4453) * (n.lat + 33.4453) ASC
LIMIT 1
-- … then format that id into the second query

-- with NEXT: one query
MATCH (n:Interseccion) WHERE …
RETURN n.osmid AS origin ORDER BY … ASC LIMIT 1
NEXT
MATCH p = SHORTEST 1 (a:Interseccion {osmid: origin})-[:TRAMO]->*(b:Interseccion {osmid: '99'})
RETURN p

And since there is no parameter binding either ($id dies in the lexer: unexpected character: '$'), that intermediate paste is string concatenation — the very injection vector the README already warns about. NEXT shrinks the surface where it is needed considerably.

Reported against frogql 0.3.0 (PyPI wheel cp38-abi3-manylinux_2_17_x86_64, Python 3.11, Linux x64).

[matiastoro]

Priority note: the correlation half of this is largely reachable today, so the value of NEXT is narrower than the description suggests — but not by the rewrite one would expect. Checked against main:

-- works
MATCH (n:N), (m:N) WHERE m.k = n.k RETURN m.k AS k

-- Type error: Variable n not found in context
MATCH (n:N) MATCH (m:N) WHERE m.k = n.k RETURN m.k AS k
MATCH (n:N) MATCH (m:N {k: n.k}) RETURN m.k AS k
MATCH (n:N), (m:N {k: n.k}) RETURN m.k AS k
MATCH (n:N) OPTIONAL MATCH (m:N {k: n.k}) RETURN m.k AS k

Two separate limits show up there, neither of which is about NEXT:

1. A later MATCH clause is typechecked in isolation — check_match_chain (src/typing/checker.rs:406) calls check_path_pattern(m.pattern()) per clause and only merges the resulting environments afterwards, so a filter inside that clause cannot see a variable bound by an earlier one. RETURN sees both, since it is checked against the merged environment.
2. An inline descriptor ({k: n.k}) elaborates into a filter scoped to its own operand, so it cannot reference a sibling variable even inside a single comma-joined MATCH, where the equivalent top-level WHERE works.

So the working correlation form today is one MATCH with a comma join and a top-level WHERE.

What no rewrite covers is the actual motivating case: an ORDER BY … LIMIT 1 in the first stage whose single result feeds the second — a per-stage projection with its own ordering and limit is exactly what linear composition buys, and a comma join cannot express it. That is the part that keeps this open; the plain-correlation examples in the description are mostly a symptom of (1) and (2) above and could be split off.

---

Generated by Claude Code

[matiastoro]

Split off: the two scoping limits described in the previous comment are now #99 — both shapes are conforming GQL (§14.3 linear composition for the successive-MATCH case, §16.4 GR 9 + §22.6 for the sibling-operand case), so they are a conformance bug rather than motivation for this feature.

That leaves this issue with the part no rewrite reaches: a per-stage RETURN / ORDER BY / LIMIT whose result feeds the next stage.

---

Generated by Claude Code