Constructing a Hyper-Program

The use of the hyper-programming system will be illustrated with an example. The example involves constructing a persistent procedure that takes a picture, performs a transformation on it and copies the result repeatedly onto the screen to give a tiling effect. The procedure takes as a parameter a procedure to perform the transformation. The main procedure also has

two data items linked into it: the picture itself and a procedure to make a single copy of a picture on the screen.

The following requirement for the main procedure is assumed, that on each execution it operates on the same picture, but on the most up-to-date version of the display procedure. This is achieved by linking the main procedure to the picture value and to the environment location containing the display procedure. Figure 4.7 shows how the example can be programmed in standard Napier88, using access specifications that are evaluated at run-time.

use PS() with fishPics : env in

use fishPics with shark : pic ; displayFish : proc( int, int, pic ) in begin

let constShark = shark

let drawShark = proc( transform : proc( pic → pic ) )

begin

for x = 1 to 30 do for y = 1 to 20 do

displayFish( x, y, transform( constShark ) )

end

in PS() let drawShark := drawShark end

Figure 4.7: An example Napier88 program

The first two lines of the program give the access specifications for a picture of type pic and a procedure of type proc( int, int, pic ). Both are accessed from an environment that is itself accessed from the root environment via the name fishPics. Inside the main block of the program a local identifier constShark is declared, with the value of the picture. This declaration ensures that the procedure will continue to operate on the same picture even if the environment location originally containing it is updated with a different picture. The program then declares the main procedure drawShark which takes as its parameter a procedure that maps pictures to pictures. Two nested loops in the body of drawShark draw a transformed version of the picture over the screen. Finally the procedure is made persistent by creating a binding to it in the root environment.

There now follows a description of how an equivalent program may be constructed in the hyper-programming system. Of course the same program could be entered if the programmer required run-time linking to the persistent store. The method to be illustrated shows how composition time linking may be used. To construct the hyper-program the programmer first enters the textual part and then positions the insertion marker at the point where the first direct link is to be inserted. Figure 4.8 shows an editor window containing the textual part of the hyper-program. Missing at this stage are the type of the transform parameter, the display procedure and the picture to be displayed.

Figure 4.8: Textual part of a hyper-program

The location of the display procedure will now be bound in. To do this the programmer navigates through the store from the persistent root with the browser until the procedure is located.

In the example the programmer selects the entry for the environment fishPics in the root environment. The procedure required is accessible from fishPics through the environment binding with the name displayFish. These identifiers will be used in this description to denote the environment and procedure respectively; however, note that the identifiers are really associated with the particular access paths shown rather than the values themselves. Figure 4.9 shows the browser display after the programmer has selected the entry for displayFish, resulting in the display of a window representing the procedure.

Figure 4.9: Browser display of a procedure value

A representation of the type of the procedure is obtained by highlighting the procedure window and then selecting show type from the pop-up background menu as shown in Figure 4.10:

Figure 4.10: Obtaining the type of a value

A textual representation of the type of the procedure is then displayed in a window attached to the procedure window as shown in Figure 4.11:

Figure 4.11: Browser display of a procedure type

The programmer now selects the location containing the procedure. This is done by highlighting the procedure entry in the environment window using mouse button 1, with the result as shown in Figure 4.12. The root environment and type representation windows have been omitted for brevity.

Figure 4.12: Browser display of an environment location

Locations in structures, abstract data types and vectors can also be selected in a similar way. The programmer now presses the link button in the editor window to link the selected location into the hyper-program at the position of the insertion point. A button denoting the location appears in the hyper-program as shown in Figure 4.13:

Figure 4.13: Location linked into a hyper-program

A similar method is used to link the appropriate picture into the hyper-program. The programmer selects the shark entry from the environment to display a representation of the picture. In this case it is the value itself rather than the environment location that is selected. The programmer indicates this by highlighting the picture window rather than the environment location. Figure 4.14 shows the display after the picture has been linked into the hyper-program:

Figure 4.14: Value linked into a hyper-program

The buttons embedded in this hyper-program are labelled with the identifiers from their environment entries. The identifiers are not significant to the meaning of the hyper-program and can be changed without affecting the program. They are used only as an aid to legibility. In some cases the system will not be able to find an appropriate label for a button, for example when the environment window pointing to the representation of the value bound in has been removed from the display. In such cases the label will be blank initially. To change the label on an embedded button the programmer presses it using mouse button 2. A dialogue then prompts for the new label.

The final stage in composing the hyper-program is to link in the procedure argument type. To do this the programmer highlights an existing value of the required type, accessed from the fishPics environment with the name fishTransformer. The programmer then selects show type from the background menu, highlights the resulting type window, and presses link in the hyper-program window. This sequence of actions results in the insertion of a button to represent the type. Figure 4.15 shows the situation before the link button is pressed.

Figure 4.15: Linking a type into a hyper-program

The programmer then gives the type button a name T, to make the program easier to read, and presses evaluate to compile and execute the hyper-program. The result of execution in this case is a new procedure value, a representation of which is automatically displayed by the browser as shown in Figure 4.16:

The new procedure value is now available for linking into other hyper-programs. This is another example of an ‘anonymous’ value: the system does not supply an initial label for any button denoting the value since there is no identifier associated with it. The procedure value has the hyper-program source code bound into it; this can be recalled later for examination and editing.

The programmer can now construct other hyper-programs that call the procedure. Alternatively the hyper-program might simply be made persistent for later use. Figure 4.17 shows a hyper-program that will link the new procedure into the persistent store. The button in the program denotes the procedure.

Figure 4.17: Making a value persistent

The linking requirements with respect to the procedure and its components have been met. Because the picture value has been linked into the original hyper-program, and consequently into the closure of drawShark, the procedure will be unaffected by any subsequent update of the environment location containing the picture, or by the location being dropped from the environment. The location of displayFish has been linked, so dropping the location from the environment will not affect drawShark, but an update of the location will result in the new value being used inside drawShark.