Adding more stuff t your symbols

There is nothing fixed in symbol searching except that is maintains a btree based on the long value of key.  The btree search itself is all of four lines of code, the real work done by two functions, find and add and they get called per node, once per node and can direct the search.

Nothing in symbol management bothers with any other field except key, and the size of a symbol entry. It has to know the latter to allocate memory, and even de-allocate if I ever finish up deletes.

The symbol entry size can be programmed on a per tree basis. One could use symbol table to locate and sort named memory segments of arbitrary use. As in:

Stack * stack = get_sym("MyStack")->def.stack; // Make a stack from named memory in c

There is blank memory in this implementation. But it is the symbol entry that needs deleting when done.  Just things one can do with a 64 bit field.  The operation above is really just a cast. The definition of Stack, the Stack and Table can actually be unions, just make sure both forms preserve key.

The union is a great tool because the syntax of a castor recasting is very simmple, yet the compiler check just as thorough. We use it above, we can allocate memory and cast it in one statement, checked at compile time.  If an application knows the various object allocated ahead of time, then create a btree root for each type, a PSym point to the top of tree, and assign the entry size on a per tree basis.  Then crate a macro:

Stack * s = NewStack("MyStack");  // Allocation of named variable

and
free(s); // should work fine if the union and initialization done right.



#define MyObj get_sym("MyObj")->def.obj);

do:
MyObj->method[0]]();
MyObj->omethod[1]();

Named method tables. One could install the methods as a compile time
const Object root= {entry1,entry2,..};

Then use object typedef directly in the symbol entry, no hassle no fuss, name and memory tied to one pointer.  I have tht, almost in xchars, part of the binary binding.  The ideas that any snippetallocates an XCB, and they get the method table with that, all the nine or ten most important xcb clalls, with argumens picked from the XCB *.  Not working on it much.

It is not symbol table, actually, it is simply the btree algorithm for sorting longs. This is a very short code, all the rest of symbol code is typedefs, initialize root, and linking or delinking; and most of that is standard. In other words, software hasn't changed, Moore's Law did, the extra capability of named objects is just an artifact.

When the key is equal to the address of memory, then a sort produces a linear array of equal sized named chunks f memory. Just flow the right side links and visit all nodes sequential in fixed size array.

Talk like c++:

#define myobj  get_sym("myobj")->def.stack;

we can do, without preparation::

myobj->push();
myobj->pop();

As long as we are willing to pay the price of symbol look up.  What kind of price? More than a c++ compiler but less than a bash interpreter. If you have a short btree, efficient, then this can be very competitive across a broad swath of applications.  In many of these cases, myobj is temporary, and freed soon after use. Their form is known, they can be typedefed without polluting the environment, with pre-processor activity and complex name layouts.

Exec command can handle namespace, object and method,k in sequence. Easy with args, just a few line of code and recursion into the table.

stacks mystack push arg; stacks mystack pop arg;

Args being used in full duplex mode.  Hardly syntax  would be the snippet to handle this, one can see it is hardly syntax.

Important point:''How can I use symbol names as first class linux objects? Because we have front end tables at the entry points,. The system we have now generates the typeface explosion character of bash and MS power script. Front end tables dumps bizarre macro punctuation. I add namespace hierarchy, left ot right util the semi-colon. No parenthesis, no quotes no dollar signs.