Qson and the life cycle of Sqlite3 tables

It is becoming clear that a Sqlite3 table is initialized and table operators set up for the complete run of the table through the machine. So the application inits the table, then steps the machine in one of a few different style loops. Their is a table context that holds the sqlite3 stmt. The ready set is prepared with row counters an limits, stmt pointer, return address, and any state variables that allow the machine to keep the stmt running.

The intent of the grammar is to release control back to the underlying sqlite3 as much as possible. So the grammar flows sqlite3 tables, they are rapidly created and consumed as scratch tables. Based on the binary convolution model between two graphs, each of which may be the null. The graph code always runs sqlite3, in all its nested glory, to completion, reaching the final return address, canceling events as fast as possible down the loops.

Is world is a descending counts of

Web:Table:Row.

Canonically stated as:

Anchor:Graph:SubGraph

So the software API is becoming clearer:
The grammar must provide application access, ultimately, to how the machine is stepped, short or long loops, just grab the next row, grab a count of rows, run a new operator, etc; Api based on the concept of Graph:Subgraph, limited to two at a time. The initialized graph becomes the key anchor between the grammar and the sqlite3 table.