More on SQL to G

Working on th engine I got the call back function working well.

SGL program can signal to the G unit any time by calling Gfun(op,...), where op is the function the SQL procedure wants G to compute.  This is working great for match points and pointer arithmetic.  But it is still in the lab.

I have a primising method working for table store jumps.  The problem here is we want SQL programmers to write and read from single source names so G can swap out the table names but keep the procedures.  A tricky problem, and I have a solution working.  This has to work, or this is the 'gotcha' that kills the idea, fingers crossed.  Graph traversal must cross table stores with relative ease, yet keep the SQL programmer free to innovate.

nterfaces.  All G compatible procedures correate self with other.  Those are the actual variable constants I had to pick.  Locally all procedure look like:
result=@(self,other)   For example:
select into result from an operation on self and other;. Write SQL against these three names and G will work.

Proprietary table, odd formats with existing procedures against them. Those table will have short interface operators to manage the graph match points. In other words, no hurry to reformat old tables and procedures, just be ready to issue G compatible output and write small legacy interfaces.. The only table G needs, evidently, are result, self and other. Bt G still reserves config.

I dumped the latest version of the to the right on the widget page. The additions are expanded use of the gfun oall,and less use of parameter mapping to procedure stateements. Pointers not tested, but their mechanism sure works in gfun.

.