next up previous contents index
Next: MandatoryOptional, and Other Up: The Generic Frame Protocol Previous: The SIPE Back End

Guide to the Back-End Implementor

 

The extensive use of generic functions within the implementation of the Generic Frame Protocol allows the modular addition of a set of methods that specialize the GFP generic functions so as to implement the protocol for a new FRS. The section is written primarily for programmers who wish to implement a new back end for GFP, that is, to provide a new set of methods that implement the GFP operations for a new FRS system.

Users of the GFP protocol see all GFP operations as either functions (not generic functions) or macros. At the implementation level, most (but not all) of the functions actually call a generic function to do their actual work, so that an FRS-specific method can be used to implement the operation. Specifically, a user-level GFP function called foo will call a generic function called foo-internal. The extra level is introduced to allow default values for arguments to be supplied, and to allow keyword arguments. In general, the foo-internal function takes exactly the same arguments as the foo function, in exactly the same order as in the argument list for foo, however, all arguments for foo-internal are required.

Since many GFP operations can be defined in terms of other GFP operations, we can distinguish those operations for which FRS-specific definitions must be supplied in a back end (the mandatory operations), and those operations that need not be supplied because they are implemented that in terms of the mandatory operations, as default methods (the latter operations are the optional operations). The set of mandatory operations constitute the GFP kernel.

The question arises as to what we mean by the term "implementation" of the Generic Frame Protocol and what constitutes a compliant implementation. We define a compliant implementation to be: A set of definitions for methods for all of the mandatory generic functions and possibly method and loop expander definitions for the optional parts of the protocol. Each of the methods or loop expanders must specialize at least the knowledge base argument of each definition with a subclass of the class gfp:kb. In principle it is possible for an implementor to provide definitions of each of the methods specialized on, for example, the class of the frame argument, without specializing the KB argument at all. Such an implementation might well work in isolation, but is not compliant and is not likely to be portable. It is, of course, acceptable to specialize more than just the KB argument. The above definition of compliance for GFP implementations makes it easy for implementors to specialize implementations simply by defining subclasses of knowledge base classes that inherit from gfp:kb. The knowledge base argument that must be specialized is called KB in all of the GFP definitions except for the case of create-kb-internal for which the knowledge base argument that must be specialized is called prototype. This is because this argument has a distinctly different meaning from the KB arguments given to other GFP functions.

Some FRS implementations will not allow the programmer to mix gfp:kb in with its own knowledge base class to create a new GFP compliant knowledge base class. This is usually because the representation uses an incompatible metaclass, such as structure-class, i.e. defstruct, or built-in-class, e.g. frames being symbols and frame specifications being stored on the plists of those symbols. Because of the above definition of a compliant GFP definition, it will be necessary for the implementor to create an intermediary class which is a subclass of gfp:kb that points to the actual knowledge base.




next up previous contents index
Next: MandatoryOptional, and Other Up: The Generic Frame Protocol Previous: The SIPE Back End

  • Peter Karp