Lightweight operators in grammar, some solutions

We are dealing with client form like:
MySchema:(a,b.d.h,r)

Where the colon is a light weight operator that modifies the standard g graph in the parenthesis. The solution is overload the colon and convert the schema into a convolution:

_@Name:(g_graph) -> Name:_@(g_graph) // How the schema is transformed in g machine

where the colon operator overloads the convolution operator with the schema modifier. Otherwise the schema sequence is run like any other convolution, but any of the graph operators will need to be overloaded, mostly with a default call to the schema c code. So we get a simple solution, the g engine and components remain simple, the schema becomes even lighter weight than convolution.

This works simplly in the machine. A light weight operator sets up the entry point to a subsequence and established the overload selector. This set up remains, and when the selecting or matching requires operation of schema. The overload is set and the already existing schema graph, a subset of the clients search graph, run as a normal subroutine call of triple.

Thus, the grammaticists, knowing what the engine is likely to do, can be a little aware when they design or proliferate lighter weight operators. Namely how much work and complexity do they want in operator overloads. We start with a general custom, you want schema, then impose them on columns of SQL because that is how g machine is going to be based in version 2.0.

The amount of c code schema needs is really minimal, the work is all in the sqlite as schema makes calls to column_text column_name etc.

How does that affect wildcards and schema?
What is: (*:) Match and collect all schema, I would think. This works because the wild card is a stationary keyword, not an operator. But, MySchema:(A,B,*) Hmm.., let's say the * means collect one time, then this collects the data by name until B, then it just grabs the next column. That implies a partial ordering we expect humans to do. Dunno, the industry will migrate toward a stable view of all this; but how soon?

Version 2.0, the target
In this versionwe want clients to type in expressive searches and get results. It should support, comma,dot,not,colon, aterisk, and parenthesis and general searches of the form:
_@(Schema:(Name.(Height,Hair)),SquareTable) //matching by schema

of _@((k1,k2,k3)),SomeTableStore) // treating the table store as a linear graph of keywords

and things like: _@((k1,*.*),SqlStoreViewedAsaGraph)

All of these with not thrown in here and there should work in about a month, and the data targets are all SQL tables, square arbitrary tables or triple tables.