Tiny opcodes, the match structure!

What happens when two triple meet?
pass or unpass, where unpass is the complete termination of current descents.
select or unselect where select means include in result
match or unmatch any of some set of keywords, by pointer.
Match by square column name
match by operator or unmatch, atribute matching, schema matching
return on bounded operator
return and close all graphs, unreturn being continue

Say, return and close on row == end. Now that is actually natural, a default opcode. But can we do a return and close on select? Give the opcode system an opportunity to open for collection and close on selection, across two key words. If so, that is great news. We can have, start collection, continue collection, stop collection; short linear opcode arrays preset before we start the general statement. The call back can retain states, like it does not with the row variable. So sql is doing insert into result, but responding to a state variable it gets back from call backs. This will work great for scanning hundreds of thousands of records, with a very comfortable overloading grammar.

So the ready set now become the match strcutre. I will assemble everything in their row starts and ends, key word pointers lists, or the default select. The structure retains state, assume ordered scans. Sp, if sql relied only on the machine, its general statement would be:
insert into result select from (self or other).key, some link, and call back on pointer pointer while not done call back;.

The machines adds a variety of callbacks, almost on a one to one with tiny ops. But it runs the little opcode array, bouncing down the compiled array on state changes in the call backs. The thing will make really fast, smart, recursive ontology generators really.