Qwiratry language redesign for SQL-shaped features

Plan/Spec for version 0.10.2 (Language Redesign): how the Qwiratry language (Query AST, query slang, and operator surface) grows to cover the gaps listed in SQL-bits-missing.md — CrUD, Grouping, and Other — without turning Qwiratry into SQL.

Companion research: SQL-AST-Qwiratry-Mapping.md, SQL-AST-Comparison.md.Backend / Location / TaOP work stays out of scope here (see Qwiratry-TaOP-Basics.md and Qwiratry-TaOP-Plan.md for row sinks and Relation faces).

Status: Writing.Scope: Language only — operators, slang forms, AST nodes, pipeline semantics, and how those map conceptually to SQL.Non-scope: Postgres/Memory Location APIs, SQL string encoding, Walker pushdown strategy internals (except where the language must expose a hook).

1. Goals

1. Make Create / Update / Delete first-class in the query language, tying mutation into Destination rather than inventing a second write vocabulary.

2. Add real grouping (group-by + aggregates), window, and unique/distinct features/operators — not approximations via ReduceOperator.

3. Cover transactions and paging (LIMIT/OFFSET) as language constructs that compose with pipelines.

4. Keep Qwiratry’s design principles: declarative Query AST, Unicode/relational operators, chained pipelines, introspectable nodes, domain flexibility (tables and other models where the op makes sense).

2. Non-goals

• Emitting or parsing SQL text in core.

• A full SQL dialect grammar or keyword-for-keyword SQL slang.

• Replacing TaOP Relation mutation APIs; pipelines and Relation remain complementary.

• Replacing ReduceOperator (⌿) — it stays a fold; grouping/distinct are different nodes.

• Row locking (FOR UPDATE, …) in the first cut (note only; see §8).

• Backend capability matrices beyond “language must not assume every Location can do every mode”.

3. Design principles

1. Pipeline position is semantics. σ before grouping ≈ WHERE; σ after grouping ≈ HAVING. Prefer that over a dedicated HAVING node unless pushdown later needs an explicit tag.

2. One Destination glyph, many intents. Extend DestinationOperator with write modes/adverbs (insert/update/delete/schema), informed by the survey in §4.

4. Survey: Create / Update / Delete across languages

How existing languages and APIs express mutation intents. Cells are representative idioms, not exhaustive catalogues. — means that family does not really own that column (or treats it as out of scope).

Rows mix command families (SQL sublanguages), protocol surfaces (HTTP, GraphQL), shell/file idioms, host-language containers, and a few graph / document peers, plus algebraic analogies (sets, logic gates, joins). Use this when choosing Destination adverb / mode names and when deciding whether schema CrUD and record CrUD share one operator.

Column meanings

• Create — Add a new thing that did not exist (row, object, file, privilege, graph, …). Fails or no-ops if identity already exists, depending on the language.

• Update — Change an existing thing in place (partial or full), identified by key / URL / path / node. Does not create if missing (unless the idiom is really an upsert — then prefer the Upsert column).

• Delete — Remove an existing thing (or mark it gone). Parent container may remain.

• Upsert — Create-or-update by identity in one operation (MERGE, ON CONFLICT, REPLACE INTO, HTTP conditional put-with-create, …). Distinct from plain Create and plain Update.

• Truncate parent + Create — Empty or replace the parent container, then populate it afresh (SQL TRUNCATE + INSERT; overwrite a whole file; replace an entire collection/document; PUT a whole resource body). The parent identity survives; the children are wiped and re-created. Not the same as Delete of the parent, and not the same as per-row Update.

Notes for Qwiratry design:

• Schema vs data: SQL splits DDL (relations/columns) from DML (records). GraphQL usually collapses both into Mutation fields. File/tee languages mostly only have blob create/overwrite/append/delete.

• Append vs update: tee -a, Raku :a / .spurt(:append), and SQL INSERT are create-shaped; true update needs identity (key / URL / path / node).

• Upsert and Truncate parent + Create are the two columns that most often collapse into today’s single Destination overwrite — the language redesign should split them from per-row Update/Delete.

• Current Proposal: Destination forms are operators, not Raku metaoperators. Bare Destination is overwrite (Truncate parent + Create). The other glyphs are composite Destination operators: ⮷// = Create/Insert; ⮷+ = Update (Plus); ⮷⊕ = Upsert (Circled Plus); ⮷- = Delete. Related Raku assignment operators (=, //=, +=, -=) are an analogy only.

• Qwiratry today only covers blob Create / Truncate-parent+Create via ⮷; record and schema CrUD (and true Upsert) are the language gap this plan targets.

5. Candidate Unicode symbols for mutation intents

There are no Unicode characters officially named Create, Update, Upsert, Replace, or Truncate for database work. The table lists the candidates from the survey discussion: usable glyphs whose names or conventional UI meaning are close enough to borrow for Qwiratry Destination modes (if we use glyphs at all rather than adverbs alone).

A compact math-ish palette (if choosing glyphs): ⊞ Create, ✎ or ↻ Update, ⊟ Delete, ⊕/⊎ Upsert, ≔ Replace, ∅ Truncate.

6. Table of Proposed Destination Operators

Expanded form of the Current Proposal survey row. These are operators, not Raku metaoperators. Bare Destination is the overwrite operator. The other rows are composite Destination operators (Destination combined with another glyph). Related Raku assignment operators are an analogy only.