Variable operations in Typeface Explosion

G machines work problems like:
G = (count=0,*.count++)

count all nodes everywhere. This requires variable operations on the graph G, (not on result) actually updating key values in the nested graph, simple pointers. But G machine also emits forms with variable operations, and G machine must maintain pointers. That problem is coming up, and I do not expect problems.

Then there are byte operations. The plan here is to use the sqlite3 regular expression code to dive into a blob of text in a key, treating it like a simple order G graph. But I am aiming for byte to be a property, not a separate set of operators.

I bring this all up, because the rules of grammar in Typeface Explosion, are not prewritten, and G machines have great flexibility, but they need agreement. Agreement among people, people generating triples, searching, dumping text. What are the set operations? Mostly functions with the property set (they are lightweight). Do we pick the first one in a set, or each in order, or all matches in any order, or first match only? Humans have to decide how variable expression execute, how they maintain order. Then the byte operations. We may not be completely compatible with industry standards.

This all involves G machines and hopefully the changes in G machines will be a simple reordering of heaviness properties, and perhaps one or two set properties. In other words, a simple table swap out. So, you see, I am deliberately vague about the rules of typeface explosion. I think the ontology industry will migrate toward common consensus, it is their problem.