Wednesday, November 23, 2011

Table set up in the current G machine

It is now configured to pop triples from either the command line or the config triple store.  The config striple store, like the self and other triple stores are views of their real table names, which I disguise with the _alias tag. So self_alias is the real table, self is the prepared view.  Self_alias is a triple store, as is result (the real name) and other_alias.  But the views include rowid from sqlite3 the aliases don't have to delclare that.

The normal procedure for me is to clean out config_alias, delete the whole thing, then execute a command that loads config from an install table written in M4 macro.  It is in M4 that I create my sql sequences and assign them to link operators. So, in general operation, there is going to be a standard install, matching sql sequences to standard G link operators.  The G link field is generally readable, but need not be.  There are three or four reserved operator IDs for G itself, so it can do directed jumps, calls and configures.  These are available in M4, but they are funny looking on the screen.

Which brings up the point.  Does the search syntax have run time variable typing? Is there a typing operator that tells G to go ascii to int? Well maybe schema does it, we already have the colon. So maybe _OP:4 tells G to traverse standard internal G operator 4.  G knows about the key word OP as its reserved namespace? Do we have to get into name space? The underscore refers to the local thingy, so we presume precadence dictates the OP key word is locally known only. But then what is the scope of the local _ operators, and so forth.  Stuff out of my league.

Anyway, I will post the m4 macros a little later.

No comments: