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.

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.

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.