next up previous
Next: Hooks in Lisp Up: Hooks and Open Points Previous: Hooks and Open Points


  The starting point and the inspiration for this paper is the notion of hooks, as known from many Lisp environments. A hook offers the opportunity to execute one or more user-supplied program fragments at some designated place in a program. From a user's point of view, hooks may be regarded as openings of a program, which are effective when some event happens, or if some condition is fulfilled.

As an example, the Lisp read function may provide for the execution of some user-supplied actions when certain kinds of S-expressions are read. Such an opening may be achieved by having one or more examination hooks in the read function, which give control to user-defined functions whenever particular kinds of expressions are read. As another example, a hook may allow user-defined procedures to be activated as a response to interactive input events, such as mouse clicks and key strokes.

From an internal Lisp point of view it is not difficult to realize a simple hook mechanism. Given the duality between data and program in Lisp, a hook may simply be a variable, the value of which is supposed to be a valid Lisp construct. If the variable is bound, the value of the hook variable is evaluated:

(if (boundp 'hook) (eval hook))

The hook mechanism may also be implemented as a procedure call:

(if (boundp 'hook) (funcall hook p1 ... pn)))

In this realization, hook is the name of a symbol whose value must be a lambda expression with n parameters. As a slight variation, a conditional activation of a function may be considered as a hook too:

(if (fboundp 'hook) (hook p1 ... pn)))

Such a hook is attached if the function is defined. The former approaches may easily be extended to deal with more than one attached function, but the latter approach, which stores attached functions in the function definition cell, does not have this flexibility.

The simple hook mechanisms shown above should not be used directly. Rather, adequate syntactic extensions [9] should be defined, which hide the underlying details. Furthermore, a whole range of semantical design options, including name binding issues, should be considered as part of the implementation of the mechanism.

The purpose of having hooks in a program is to open the program at carefully selected places in order to improve the reusability of the program. Hooks allow the user to customize and extend the program without having to know or to affect the source description of the program. The attachment of functions to hooks are intended to be done dynamically, at the time of execution of the program. Program customization may, for instance, be used to alleviate minor inconveniences of an application. Program extensions may result in an integration of an application with other applications.

The following items describe the characteristics of hooks, which we find most important:

  1. Announcement.
    A hook in a program is only interesting if it is announced as part of the program's programmatic interface. The announcement makes the hooks known to the user of the program. Equally important, the announcement commits the designers of the program to keep the hooks relatively stable during the lifetime of the program.

  2. Late attachment.
    A hook should remain open until execution time of the program. Elimination of hooks during macro expansion and compilation should be avoided.

  3. Selective opening.
    Neither totally closed programs nor uniformly open program are ideal. A closed program is a bad starting point for reusability, whether customizations or extensions. A uniformly open program may be bad too, because such programs tend to contain little or no guidance on how to exploit the openings. It is the author of a program who decides which aspects of the program to open. It is a matter of good program design to place the openings appropriately.

In summary, the purpose of hooks is to provide for announced, dynamic, and selective openings of programs.

As mentioned above, the starting point of this paper is the basic hook mechanism, but the main focus is an analysis and a discussion of a broader class of mechanisms, which we call open points. In section 2 we discuss various hook mechanisms in Lisp, as described in the literature and as present in some Lisp systems and applications. In section 3 the meaning of an open point is defined, and in section 4 open point-like mechanisms from a variety of programming languages are surveyed. This discussion reveals to which degree the openness, as provided by hooks in Lisp programs, can be obtained in other languages and in other paradigms. In section 5 we return to the hook mechanism, where the variations and the design issues of hooks are considered. The discussion leads to the definition of some Lisp constructs for hooks, which abstract the underlying technical details. Finally, in section 6 we discuss a set of tools that supports the handling of hooks. Major parts of this section are based on a practical example. Among other issues, the tools address the problem of how to announce hooks for users of open programs.

next up previous
Next: Hooks in Lisp Up: Hooks and Open Points Previous: Hooks and Open Points

Kurt Noermark
Wed Mar 6 09:44:24 MET 1996