HYDROGEN: Extensibility (by alaric)
Feature sets
Some computers have hard disks. Others do not. Some have advanced power management capabilities, and can measure the temperature of their CPU. Some have dedicated graphics processors connected to high-resolution displays. Some just have a serial console.
I've found that application's use of such devices falls into roughly three categories.
Sometimes, an application absolutely requires a certain bit of hardware. An image viewer can't do anything without access to a frame buffer. So for every feature that a HYDROGEN implementation might have, but that is not required by the core of HYDROGEN, we define an optional set of words for using it, and we allocated a feature name to that wordset. If software requires that feature, they can state it using the require word, which aborts interpretation with an error if the feature name it parses is not present on this system. So one could say require device:framebuffer at the top of your image viewer, then proceed to use words like device:framebuffer:blit to copy pixmaps to the framebuffer.
Sometimes, an application can benefit from using a bit of hardware, but doesn't depend on it. Since HYDROGEN loads code by interpreting a set of instructions on how to compile the code, we can make decisions at load time, sort of like C's preprocessor macros; so we can check for the presence of features, and modify the code we generate. This is done with the feature? word, which again parses a feature name, but this time pushes a boolean indicating whether the feature is present or not. So our image viewer might, if a pointing device is available, offer the ability to interact with the image using it.
And sometimes, an application needs totally dynamic access to available hardware. A TCP/IP stack might be interested in all the Ethernet, Wifi, and serial (for PPP) interfaces available on a system, while dealing with the fact that this list may change with time (devices can be hotplugged!). For these applications, we provide the device-tree feature. The device-tree wordset provides for the application to register an asynchronous callback that is invoked whenever devices appear or disappear; then there's a set of words to find the type of a device, query its details, and to find out how it is organised in a logical connection tree.
For each type of device, there's a corresponding wordset, such as device:ethernet - which provides words to find out how many devices of that type are available on the system and then the specialist words to interact with an instance of that device type; all that device-tree adds is a central dispatcher for device addition/removal events, the requirement that the cell-sized device handles used by the device:* features are distinct, and some general words that can be used on any device handle to query its basic details - and removes the concept that the list of ethernet interfaces returned by device:ethernet:list won't go changing randomly.
Of course, not all features just add new words - some might further refine the semantics of core words, or other parts of the system. For example, the c64 feature adds support for c64, u64, and s64 types, which includes words like u64+ but also adds u64 to the list of types valid in SHUFFLE[ and BEGIN[ declarations.
Wed 15th Jul 2009 11:05 pm 
Subscribe