next up previous
Next: Programming Language Support Up: Hooks and Open Points Previous: Summary

Open Points

  The hook concept, as defined in the previous section, is tightly connected to the mechanism of procedure activation. In this section we will introduce a slightly more general understanding of the concept, which we call open points.

An open point is a documented, behavioral parameter of a program which is required to support default binding and execution time binding (see below for a more detailed characterization of each of these).

Being a parameter implies that an open point is a named definition of an entry, which must be bound (explicitly or implicitly) before execution time. The adjective ``behavioral'' emphasizes that parametrization of expressiveness and action is of primary concern. Open points are neither envisioned to capture simple parameters nor type parameters. An actual parameter serving as the binding of an open point will typically be a parameterizable procedural abstraction.

In addition to being a behavioral parameter of a program, an open point must obey the following requirements:

  1. Default bindings.
    It must be possible to have default bindings of the parameters that are used as open points. It implies that a program with open points will serve as a full-fledged, executable application regardless of any explicit binding of the openings.

  2. Execution time binding.
    It must be possible to bind the open point at execution time of the program. It implies in particular that the binding of an open point must not be prevented by any transformations carried out during the program development process.

  3. Documentation.
    The purpose of, and the requirements to an open point must be described as an integral part of the opening. The documentation of open points contributes to the separation of internal program aspects from external aspects.

Point number one makes it possible for a program with unbound open points to serve some specific needs. If the user wants to change some of the open behavior of the program, the information called for in point number three gives the user some guidelines about how to exploit the open points. Point number two guaranties that the open points are not optimized away, e.g., as part of a program compilation. In the definition and the requirements above we have ``left open'' the issue of further binding of an already bound open point.

In order to bind an open point at program execution time, it must be possible to incrementally affect the program at that time. Programming the procedures that binds the open points is similar in nature, but presumably different in scale, to programming the closed parts of the program. In incremental programming environments, such as in Lisp systems, the programming of these procedures does not cause problems.

In more traditional, non-incremental environments, it is much more difficult to actually bind the open points without directly modifying the source program. There are at least two possible solutions to that problem:

  1. Increased incrementality of the environment.
    If small changes of a program can be done without re-processing the entire program, it will be possible to use this incrementality to bind the open points of the program.

  2. Inclusion of a dynamic extension language to the environment.
    Instead of adding incrementality to a natively non-incremental environment, an already open extension environment, based on for instance a Lisp dialect, can be included into the program. The extension environment must be interfaced to the definitions and the functionality of the underlying program. In a framework like this, the binding of open points is supposed to be done through the extension environment.

Incremental programming environments for languages such as Pascal and C have been subject to much research (see, e.g., [17,16]). The idea of having a flexible extension environment is known from the GNU Emacs text editor [20]. The extensibility and the programmability of this version of Emacs are due to an integration of a Lisp environment into an efficiently implemented text editor framework. Currently, there are some efforts going on to generalize this idea to arbitrary areas of applications.gif

Given the definition of open points from above and the definition of hooks from section 2 it should be clear that the hook mechanism is a concrete example of open points. In the following section we will analyze to which degree a number of other programming languages support the notion of open points.

next up previous
Next: Programming Language Support Up: Hooks and Open Points Previous: Summary

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