The fundamental match loop

The whole point of G is managing the following loop:

// if that thread is ready, run the select sql
thread = other();
if(thread->match_state==0) {
triple(SQL_MASTER_SELECT,0);
thread->match_state=1;
}
else { // else that thread runs to its match point
current_thread->state=0;
current_thread = thread;
for(;loop() != G_DONE;);
}

Two grammar sequences describing nested graphs have match points at some nodes. The one says,'I'm ready to try an sql select, is the other guy? No, then runs his triples through the machine, The presumption in the grammar is that when the graph opens a descending sequence, then all the priors about output formatting and select filtering have been established, as well as stop points.

I think I have an improved master select:
select self.key,self.link,self.pointer from self,other
where self.key == other.key
and self.rowid == SelfRow() and other.rowid == OtherRow();

Use the gfun call backs on rowid compares. I am shooting for this in version 2, a bit of an upgrade. If I get that working, the the gfun can start following descending set/descent subgraphs. Really simplifies output filtering makes for efficient graph matching.