More on the indexing problem

More stuff I need to unpatent.
A nested index look up is a graph onvolution. Consider:

G1 = {a1,b2}
G2 = {a0.{b0,b2,b3},a1.{b1,b2}}
then @G1,G2 gives me the final conclusion.
So the grammar in the Ugly handler can treat this like any other convolution. Except for one thing.  This convolution is all set up except for supplying G1, ready to run with chained operators.  Second, G2 is prepared, the key  values indexed by Sqlite3, isn't that nice!!  The grammar engine has the ready set, it can pop in one set in place of another.  The ready set has all the binding variables and call back variables ready to go.  So a look up is, pop in the prepared ready set, point to G1, and run the table. Since table jumps are implicit in the Q operations, the thing will naturally nest through Qson standard, or even square table  if set up.

So I make the Qson standard, default math_step operation work and I get nested indexing or free.  I really have to make sure this is unpatentable, prior art.  Nested indexing has been around, the only  thing unique is stepping, but bytecode has that covered. Anything peculiar to sqlite3 is, well, who else is doing it? So I think we are clean. First thing to do after alpha testing complete.