Sunday, November 27, 2011

G predicates in the machine

I guess we are supposed to use the word predicate for what the machine thinks is link. Never mind, all triple grammar has the same format: key,link,pointer. The triple machine can process any defined triple properly. Some of the triple predicates, link, are operators which the machine handles internally, and some are defined for activating match,format or select functions. Anyway, the internals link values are:
G_EXIT - Nothing left on this triple sequence
G_POP - There are three of these, they pop the next triple from one of three triple tables, all predefined names. The pop operator for a particular table is bound to the table when a triple frame is open on the table and usually not called explicitly.
G_CALL - Call the triple sequence identified by the row in key on the current table, if one knows what one is doing
G_SWAP - Pop from the other table.
Then we have the internals dealing with sql statements, mostly variations on the sqlite3 API set.
G_EXEC - Directly execute the key text as an sql
G_SQL - Step the sql statement in key. The output passes thru the matcher, formatter.
G_CONFIG - Install an sql sequence to the operator specified in key. Included is the opportunity to specify the bind parameters from the two open triple frames, like start, end, match function. This is a multi-step process and violates G grammar.
G_DUP - make a copy of the operator installed in key, duplicate it and run it.
G_SCRIPT - Recover the installed script for the operator in key from sqlite3, and print it

These are the ones likely to survive version 2.0.

How's my line count?
I have the triple machine solid at 230 lines, and the general thread and grammar handler at 250 lines.  I think I can get version 2.0 in under a total of 520 lines!

No comments: