Most programs written in persistent languages access data in a persistent store. Programs contain denotations for this data, which may include values, store locations that contain values, and types. At some stage during the software development process the denotations in a program are resolved to the actual data. The terms defined below will be used in describing this resolution:
data item: a value, or a location containing a value, in the persistent store;
access path: a description of the position of a data item in the persistent store;
access specification: the access path of a data item together with a description of its
expected type.
Each program contains an access specification for each of the data items that the program links to. In PS-algol and Napier88 this code is executed at run-time and any related errors occur at that time. Errors can arise due to the data not being present at the specified position in the store, or its type being different from that specified. In addition to accessing data items, programs can also access types in the persistent store but the nature of this access will be discussed later.
Often the programmer knows that some of the data items linked into a program exist in the persistent store at the time the program is written. In such cases a language system could allow the programmer to indicate the required data items by interactive gesture with a mouse, instead of writing an access specification for each data item. Graphical representations of the appropriate data items of the store could be pointed to by the programmer. No access specification would be required as the access paths and type descriptions could be obtained from the system’s internal representation of the persistent store.
The linking of the program to the data items specified in this manner could be handled by the system in several different ways. It could perform the same actions as if the programmer had written normal access specifications. It would thus verify at run-time that the store contained data items with the specified access paths and types, and then link those items into the running program. Another strategy is to link the data items directly into the program as it is written.
This chapter will explore the possibilities of the latter option. This scheme requires a change in the nature of the source program: the textual description of the computation is augmented with tokens that denote the persistent data items the program accesses. By analogy with a hyper-text graph, in which a piece of text contains embedded links to other pieces of text, this type of source program is termed a hyper-program [FDK+92, KCC+92b]. It consists of a textual source program with embedded links to values, locations and types. To construct a hyper-program the programmer types in program text and then inserts tokens that denote data items identified by pointing to their graphical representations.
Figure 3.1 shows an example of a hyper-program. The hyper-program contains both text and a token that denotes a data item in the persistent store, a procedure to write out strings. The hyper-program contains a link to the procedure itself rather than an access specification for it.
persistent store writeString hyper-program for i = 1 to 10 do begin ( "Hello world" ) end direct link procedure value Figure 3.1: A hyper-program
The tokens in a hyper-program denote references to, rather than copies of, values and locations in the persistent store. This contrasts with linking mechanisms in file-based languages such as C [KR78], with which a program can be linked to a number of other programs. These involve copying code from other programs into the main program code. In addition, hyper-programs can contain links to any data items rather than just to sections of code.
A number of benefits of using hyper-programs will be described. These are: • support for program composition and software reuse;
• being able to perform program checking early;
• being able to enforce associations from executable programs to source programs; • availability of an increased range of linking times;
• reduced program verbosity; and
• support for source representations of procedure closures.
The principal requirement for supporting a hyper-programming system is a persistent store to contain the program representations and the data items corresponding to the tokens in the programs. The assumption is made here that the store is stable and that it supports referential integrity. This means that once a reference to a data item in the store has been established, the data item will remain accessible for as long as the reference exists.
Secondly, the hyper-program source representations must be denotable values in the programming language. Linguistic reflective facilities are required to support the conversion of hyper-program representations into executable programs. Where the executable programs produced by reflecting over the hyper-programs are themselves language values, a suitable representation is required. One possibility is to use procedure closures; these are already supported as first class values in a number of languages.
A third requirement is for tools that provide the programmer with the graphical representation of the persistent store. The representation shows the values, locations and types in the store and the links between them. The programmer can point to the representations of specific data items and obtain tokens for them to be incorporated into hyper-programs.
These implementation requirements are discussed later in Chapter 6. This chapter elaborates on the motivations for building a hyper-programming system and on its benefits. To be useful in practice a hyper-programming system will also have to support additional facilities for ‘programming in the large’, that is, building large applications from smaller components. These include facilities for controlling the sharing of components between applications, for
limiting the visibility of some components for protection reasons, and for imposing a degree of partitioning on the persistent store to aid intellectual manageability and execution efficiency. A model to support these facilities, the hyper-world model, is proposed.