Currently Keykos provides a degree of low cost dynamic type checking. If a program bug results in a key designating an object of some type other than anticipated by the programmer, orders on that object will likely be invalid and rejected by the conventional return code kt+4. This usually results in a useful error report. Experience leads us to wish for an even greater probability of catching runtime type errors. A further task is coordinating header files that map symbolic “method names” or order codes such as “Node__SwapKey”, to 32 bit numeric codes. The command system is hard pressed to do so. Here is a scheme that declares the numeric code to be a hash of the mnemonic code. The command system can now compute this hash and gain high probability of detecting type errors at the same time.
KCPP is a program that transforms C (and assembler) domain programs before the normal preprocessor and compiler see the program. I write this note in blissful ignorance of the structure of KCPP. Thus I may modify this before I am done.
KCPP must see the orders at the same time and build the dispatch table. The table could be placed after all entry points. I am inclined to make the dispatch code perform a goto since I know how to get the advantages of a call given a goto but not conversely. The result would have the feel of a C switch statement. Ugh.
A minimalist approach is to present KCPP with a type name and a list of pairs of order names and compiler identifiers. Here a “name” is an ascii string. KCPP would build the associative dispatch table leading from hash value to whatever sort of runtime value the identifier identifies. The same mechanism might then be used to dispatch to various routines, or various labels, at the programmer's option. This scheme allows for domains that must do something before dispatching, such as locating some data structure depending on a data byte. This has the benefit, I think, of requiring only a local transformation by KCPP. Some objects will want more than one dispatch table. The minimalist scheme supports this naturally.
The alternative of building this structure at run time suffers from being some combination of awkward and inefficient. It takes extra space. It could be done during object creation but then the dispatch table is not shared between siblings. It could be done before factory creation but that would require new hooks in an already obscure part of the system. It would be good to provide a version of the function for code that did not go thru KCPP so that new language support need not negotiate with KCPP wizards.
The next conceptual step is to put the code for creating dispatch tables into an object. Such an object could also respond to a command system to hash an order. We pursue this scheme for defining objects is a familiar way to define function.
The order hasher is an immutable object that accepts an ascii string consisting of the type concatenated with an order, and returns a 32 bit order value. Another order takes an ascii type name and returns a mutable object primed to produce a dispatch table for a collection of subsequently sequentially delivered ascii order names. How to return the dispatch table?? The dispatch table requires the services of the loader to resolve the symbolic links. The reductionist answer is the ELF format. We already trust the loader function but I wish there were a shorter clear description of the ELF format.
This object does not serve the current practice of compiling under Unix. I don't like to sway too much design by such considerations, however.
On the other hand it seems clear that we need a string hash function. We have SHA1. We need a dispatch table constructor and a dispatch table lookup. The lookup routine is small and needs to be called without the expense of a gate jump. Just now I see no engineering reason to not merely make all three a simple loadable routine. The benefit of sharing the lookup routine is small and might be negative due to fragmentation.