Variable expressions in the G machine

In the convolve operation between two subgraphs of G:
Z = @(X,Y)
only the graph Z is modified in the execution unit.  Any change in the world of G is done when the traversal in G is complete, then the G machine can decide where Gout is connected. So, consider:

X = (count-0.*.count++) and Y = localhost
Z = @(X,Y) leaves X and Y unchanged, but Z =  (count = N) 
where N is the number of nodes in localhost.
So, rule 3 (is it?) the World G remains unchanged at all times until an append graph or replace graph is executed outside of the execution unit.  Variable management is much simplified.
The simplicity results when a convolution requires a recursive convolution.  Gout, in its current state, as all if variable declared up to that point, and their current values are correct.  Any new variables down stream in a subgraph will be local to a recursive call to convolution. So the mechanics of a recursive call, take the variable list and values on Gout and ship it over to the new recursive.  On return, update the values.  it works, but will cause problems later down the line when the Gout variable set grows.  Eventually Typeface Explosion will have to add scope to variable declarations.

Mechanically in the G machine I rely on SQL for all operations, and Gout is always a consistent table store in G format.  So, a select * from Gout where operator == DECLARE; gets me all the declarations on Gout up to the current descent.. The machines gets those, calls something like:

G returned = @(]subgraph(X),varlist],LongJump)

The sent graph has a variable list in the top level node.  This is a prefect graph in G world, and was created by using append graph to graph.  Th update gvaluse of the variables restored to local Gout, and the G return residual appenped at the call point.

So what is the current design of my G machine?
I have two operations,a  config an operation that assigns an SQL sequence with an operator  This config also defines the mapping between SQL arguments and machine state variables, mainly rowids and optional table store IDs.

And second, an an atomic SQL operation, leaves Gout with a termination status containing the rowid for X,Y where the operation found a stop.  The SQL return status also contains the stop code.  Return conditions are the last record on Gout after an atomic operation is complete.

Each of these is about 20 lines of code. Everything else is defined in my editor and the  M4 thingie.