We have several problems, some more pressing than others. We have several ideas for solutions, some more feasible than others. The problems overlap considerably, and so do the solutions. It would be good, I think, to coordinate them both.

Solution

Fairly early in the implementation of Keykos we began to consider the possibility that the alleged type call (order code kt = 0x80000000) would, in addition to the one word result now returned, conventionally return also a memory key with some sort of descriptive material. One impediment to this plan was finding some format for the material in that segment that would be very easy to parse and also be extendible.

Such information might include:

It is clear that such material should be accessible by means other than having access to the object, for I may need to understand the power of some key that I am not authorized to wield.

It seems wrong these days to propose a computer representation for natural language without some form of linking.

Some configurations might not afford the space for this information. Such systems are unlikely to run command interpreters.

Problem

The immediate stimulus for this note is a desire to augment the command system to recognize symbolic order codes. To many this is the most severe difficulty in reading command scripts. Our primitive command system now converts part of the command string into a 32 bit number. It currently accepts “+” or “-” between decimal numerals. It also allows the symbol “kt” which stands for 231 and which is inconvenient to denote in decimal. Perhaps providing a symbolic order code would be implicit permission for the command system to invoke the key first to look for a mapping to order codes.

Problem

Another problem is this area is polymorphism. After some type of object has been spread around as well as software that uses that type, a new more elaborate type is invented that conforms to the old contract and some new ones too. The alleged type should be the same as the old in order to accommodate the old software, but the distinction should be possible to software built with the two types in mind.

The following scheme almost works in Java. The class coercion in Java must quickly determine if some particular coercee suits some particular coercand. If at load time the loader does a depth first enumeration of all classes, then a simple range check determines whether one class is a subclass of another. Java’s dynamic loading can introduce new subclasses after instances are already deployed. If the range check fails then the runtime can run up the super class chain until a class with a range value is found. Then the test is still fairly quick. I don’t see how to use this in Keykos yet.

Solution

We have considered hashing the symbolic form of order code to 32 bits which would serve in place of the current order code. See efficiency for remarks on runtime efficiency of this scheme.

I speculate “What can KCPP do for us?”.

It is a considerable disruption to change all of the order codes of all of the objects, but both sets could remain available for the proverbial “while”.