How's the software going, you ask?

I have this working (in the lab version):
_@( (k1,k2,k3),((w1,w2,w3),(x4,x5,x6))

Al the parentheses open and close properly with no lost data. In this case, the machine starts left, opens a parenth. It finds the opposing graph is idle, so it points the triple machine to the other graph. The parenth is popped off, g finds the opposing graph is now ready. The general select and match returns matches between the k keywords and the w keywords. The parenth on the right close at SQLITE_DONE. The process repeats, g finding the second parenth and opening that to continue, now finding the x word matches. It works because sqls are not nesting internally so G can easily update the thread row pointers and skip past the completed select blocks.

The one I am working on os this:
_@((k1,k2,k3),(w1,(x2,x3),w2))

In this one, the parentheses nest within a select. So I think I might need the gfun call back to determine proper rowid from within the SQl statement. Thus by managing rowid, the internal sql statement executing is updated thru the nested queries. Dunno all the details yet.

What about output?
The output, without modifying match function, is the default match on keyword and link, I would think. But any open triple frame that is running has its accumulated match, collect and format operators, they are light weight operators, like NOT and SCHEMA, would have preceded the open frame, so g knows what to do.
What is the grammar on schema then?

MyScheme:(schema pattern),(keyword list)

That is, the schema is applied to each element in the remaining set of elements. So from the machine's point of view, the script:
MyShema:(schema pattern) is a perfect valid form though it encloses no select function and has no effect, there is no way for G to look back and find the schema, even if referenced by the word 'MySchema'. G is a forward looking grammar, no backward references.

How about proprietary tables with an unknown number of columns, not nested triples?

On simple solution for version 2.0 is to install a different select, one that uses compound operators to pick off the columns, one by one, and presents them as triples to G, use install to change the operator on the general select. Automatic set up and install for proprietary tables is still under design, dunno the details.

Swapping threads, even across tables, here is the code:
void swap() {
TRIPLE_THREAD *thread;
thread = current_thread;
if(thread != other_thread)
current_thread = other_thread;
else
current_thread = self_thread;
loop();
current_thread = thread;
}

The machine just alternates between the two nested graphs. All the machine knows is that each graph has match points which it can recognize. A match request by the current thread causes the swap. It is the grammar of matching, typeface explosion, that must be consistent in the use of match points.

What is that thing loop? It just runs the current triple thread through the triple machine, the grammar of triples is self directed. Each triple is popped off and it may open a new select thread or modify the match, collect, and format function. All of the internal functions of the machine are available as triple predicates. For example, just use the G_SQL operator to execute the general sql statement in a triple: <0> Make that the only triple in your file. G will just execute the sql statement generating tons of output, which it runs through the most recently specified match,collect and format modifiers. Add a schema if you want, how would this look?

MyPrioprietaryData =
MySchema:(colname1,columnname4.columnname8,columnsname0),

then somehow add in your sql statement as text, specify the G fun and close the grammar.

So there are going to be some ways to kick into the machine internal function, g literal triples made available to the grammar. But the point is, even if we constructed the triple by hand, the machine will gladly accept any proprietary sql statement to generate potential match keys.