Done with schema

Now doing output filtering. This is the problem where the client specifies set/descent ordering in the pattern select, using the comma/and link traversals. Following the pattern means tacking the descents, and rejecting their future matches when they terminate.

Any triple arriving from sqlite will be accepted for output if it is a continuing true result of the continuing descent. It is a true result based on the previous node, the previous matched node, the modifiers and the current accumulated truthfulness. If grammatical descents can guarantee an exit property at the last node, then that helps. The sql select can always report the previous node of any matched node. So G has a lot of tools, enough tools to confuse me. Remember, on output filtering, descent failure means the machine has to tack back to the previous match. Then reset the output row pointer pointer, deleting the rejected path. But the triple frames with their pointers make this a snap.

Then there is output destination: Spew triples to console or to any arbitrary table. I might ditch result, and create and output control operator for clients. Make the configuration of output a variable users can adjust.

Anyway, output is now the order of the day, then testing, testing and testing. Mainly large arbitrary square tables, and console sequences of complex TE language Include pasting very large queries straight from the notepad editor to the G console, just like sqlite3.

The Grammar we get in version 2.0:
The punctuation: , . ( ) ! :
Keywords are whatever sqlite3 wants them to be. The schema operator applies to sql column names only. But they can be matched with no problem, just dunno what their meaning is so far, except sql column names.