Coding!!

Here is how I implement the truth code. I have tiny ops like:

1: pass and don't collect while not match keyword
2: if not matched, go back one
3: pass and collect
4: if not match go back one

The match structure contain a list of four or five maybe, assembled just prior to launch. This list is the match vector, an sql statement steps through it in one of the three standard methods, a call back from a where statement from insert, data from a select statement, or single stepping from the command line. It akes sense, the machine has only one goal, launch the statements with a match vector.

One of the opcodes can update row pointers, close the statement and prepare another sub query. There will be one or two types of match key and match link codes. There may be a jump to begin, increment or go back to cycle through the states pass or collect. The sql directs the stepping of call back through the little set, more intelligence in the statment, less action by G. For example, elements of the tiny match vector can be accessible in compound statements, looking for stop and start conditions. Such a statement would shift through large arrays, rarely interrupting the machine., especially if it could bind to parts of the tiny match vector on launch.

In total, the machine will have a match structure, that contains the tiny match vector. In this structure, the code can assemble just about anything the statement might need, so we might end up with a much simpler set of binding options, reducing that code a bit. I am still aiming for 750 lines of code.

So, I have the match opcode set, small routines accessible by three methods. I have tiny op defines, I try to follow the slite3 standard without overdoing it.