The virtual machine assumes a high speed graph sequencer drives traversals. The rules of grammar at the graph layer dictate that all arguments, in or out, are nested store table, in which we include sql square tables with internally managed schema. The machine has a default graph format for square tables.
So consider: @(A,@(B,C))
Five tables, the output, the intermediate and three inputs. In the machine the nest is structured as the parent-child relationship between filter contexts. At any match event. the rules state the machine must have complete tables and stable table pointers. This is the linearity requirement, mainly over the dot operator, as the coma is often overloaded. Hence, the micro sequence at a match has options, in real time, run the outter or the inner loop.
Where and how are tables identified? Good question, how about a key word on the @ operators: OutputTable@(A,B) and square$OutPut@(A,B) Dunno, call me when the TE committee meets. Can the machine do square tables on output? Absolutely, as long as the schema is supplied, and someone wants to write the code snippets and argue the grammar.
So I am assuming the @ gets me to a table, and every table is the expression of a convolution. Even in these simple cases: TableName@, which impies TableName@(*), implies TableName@(_,*) or some hierarchy like it. I am going to use it until I discover the conflicts, then I refer back to the imaginary committee.
A hint aboutt what I am pondering. We need a mechanical graph sequencer which in general works in a horizontal or vertical mode, but has nested store as its underyling model. The sequencer machine should be bit more intelligent at casting than is sqlite3, but mainly should have robust methods for various forms of graph oriented jumps, by rowid. Call that the graph virtual machine, it provides basic nodal traversal via the pointer; offers the key and link matches, knows square tables but refers to them with graph syntax. SQL on graph steriods.
No comments:
Post a Comment