Thursday, January 17, 2019

Symbols and entry types

typedef struct Sym {
unsigned long key;
Val def;
int type;
struct Sym * less;
struct Sym * more;
struct Sym * parent;
Val symlink; // arbitrary use
} Sym;
typedef Sym* PSym;

 The key value is an unsigned 64 bit integer, symbols just sort a set of unique 64 bit integers in a binary tree. The key value, its definition is anything that the user can fit into a 64 bit integer.

 But, a symbol look up can be preceded by a namespace look up, and that yields a method symbol set for the named space, both at a minimum one extra step.

The type of def can be symbol table entry or a snippet entry point, or a special library entry point, or a plain integer ID, but that is equivalent to a key value anyway, or a macro entry index right back into args or an RGB color or eight bytes of char.

 Remember, we can Huffman encode repeated phrases in our text editor, and with a sound font interface,pre-rasterize. The long key value will, after few steps, lead right to the proper compound font. Huffman encoding IDs for game widgets is the most common use of the technique, nothing faster than integer compares to descend a tree, but we still get plain text in the deal.


Val is what you make it:

typedef union { 
unsigned long l;
void * vp;
char * s; 
EntryType *entry;
struct Sym * sym;
char txt[8];
} Val;

A symbol has one of these.  But the symbol table itself has no restriction, the Val above isbasically over kill for symbol table. Symbol table ignores Val, except for print out, they are never looked at in symbol table.  Snippets invent their own val list, I have a Val that includes every single xcb thing ever required to put text on rectangle, it helps to carry a bag of these xcb things n a table.

Entry type is the universal, so all the way through look up and execution there is no change in call format, it is one entry point fter another, generally descending the args list, and ascending it on return.

No comments: