The standard selects reveal themselves

My parentheses went away, and I was using that to trigger the select operator. So, when does the select operator start, say on a script like:

@((M:Name.Weight,George.200),SomeListOfPeople);

The first graph keys off the name George, that is the first set element after the schema. The machine opens a sub query whenever there is a forward pointer, meaning a set element jump, it attempts to start a descent if the coma operator open an element. So it naturally does a Turing complete traversal of either graph.

But in @(G1,G2) G1 and G2 have to match at the sub query launches. The first G sets up new graph pointers, then hands off to the second who sets up its own, or may reject based on the node and accumulated select function. Consider this one:

@(*,AnyTable)

That, depending upon the chosen meaning of the * wild key, says, on the first graph select from rows 0 to infinity when we select with start and ends bounds. So it always return select based upon row limits. Sure, we can do that sub query.

I will make the parent query restart at the proper time with the update graph function, it moves the row selector to the next set element. But it might just happen naturally. All of these should be possible match requests:
(*.(height,weight)) Just the height and weight.
(*,name,weight)
(name,*,weight)

But just because we can write them does not give them total meaning. Do we always match structure? Well I suppose if it is in the syntax. Any sub graph of structure can be replaced with the wild key. If there is schema, then we can force the output to have structure, or can we?

Schemas do neat things, sub queries do neat things, but they all have modifiers, simple methods to modify their select function. So, less a function of software, and more a custom of database geeks adopting informal standards about default and modified operations. The machine needs defaults, things is does in the barest cases that cause us to say, OK, that makes sense.

How is this thing going to handle wild key operators, not operators?
We have the compound union operator, except operator, intersection function, a lot of flexibility in the master sql select statement.  where other.key = '*' or... in a compound where clause helps also.  Hence, the importance of making the source code widely available, so sql programmers get it.  Once they get the concept, then they will make is spin at ultra speeds, with specialized tables and statements to go along, but still conform to match points.  At that point, all the major data warehouse vendors will want these machines every where. At 800 lines of free c source code, who can blame them?