Capsule(ID:6992/cap007)

Modular extensions to Pascal 


CApsule is an abstraction mechanism for Minnesota Pascal 6000, influenced by the CLU abstraction mechanism


Related languages
CLU => Capsule   Influence
Concurrent Pascal => Capsule   Incorporated some features of
Euclid => Capsule   Incorporated some features of
Minnesota Pascal 6000 => Capsule   Based on

References:
  • Giacomucci, Alessio and Friedman, Frank L. "Capsules: A data abstraction facility for Pascal" pp154-160 view details Abstract: Described is a data type abstraction facility that has been implemented as an extension to the University of Minnesota Pascal 6000 compiler. The facility provides an encapsulation that establishes a static scope of identifiers with controlled visibility. The facility was developed primarily for instructional purposes for use throughout an undergraduate computer science curriculum in which Pascal is the major language for program implementation. The paper begins with a brief background in which earlier abstraction facilities influencing the development of the capsule are described. Then a description of the capsule and capsule parameterization (generics) facilities is provided, followed by an outline of the implementation of the capsule in a Pascal compiler. Plans for a generic capsule library and some comments concerning the use of the system in undergraduate instruction at Temple university are given in the last section. Extract: Introduction
    Introduction
    A substantial portion of recent research in programming methods has focused upon techniques for producing programs of high quality and reliability - programs that are easier to understand, modify, and maintain, and which, through suitable verification and/or testing techniques, can be shown to perform as intended.
    To a large extent, the quality of software systems depends upon the development methodology used. However, the choice of a language can have a major impact on the effectiveness of the methodology. The language in use is especially important when a particular method is first being introduced in an instructional setting. A methodology is far easier to motivate if it can be applied easily in a given language; the ease of application is to a large degree dependent upon how well the language constructs mirror the forms used in the methodology. It is common knowledge that matching a language to a methodology increases the likelihood that the methodology will be applied. Thus, the language can have a profound influence upon the way in which its users approach a problem solution.
    Recent research in programming languages has focused considerable attention upon the development of procedural, control, and data abstraction facilities useful in the support of programming methods similar to Dijkstra's structured programming. While this approach may take many forms, it generally involves developing a program by means of a step-wise decomposition of a problem into its smaller and more manageable parts. Numerous proposed languages, the earliest of which was Simula 67, have evolved from these efforts. Others, such as Alphard, CLU, Concurrent Pascal, Modula, Euclid and Ada have demonstrated considerable advances in terms of the support provided for abstraction facilities, especially with regard to data abstractions.
    Unfortunately, none of these languages has as yet received wide commercial use. Instead, both commercial and instructional users have continued to use languages such as PL/I, FORTRAN, BASIC, and COBOL which provide considerably less support for abstraction.
    Recently, Pascal has received greater attention from the computing community. While Pascal provides considerable general improvement over PL/I, FORTRAN, BASIC, and COBOL with regard to abstraction features, its data abstraction facilities are still markedly inadequate for all but the simplest programming efforts. In teaching computer science, the major shortcoming of Pascal is not readily apparent at the introductory level. However, it becomes increasingly annoying in all subsequent courses in which more complex computing problems are studied. At this point, it is important to begin to train students not just in the art of problem decomposition, but in decomposition based upon the recognition of data abstractions. As a problem is analyzed it is essential that the important data objects and the operations performed on these objects be isolated and carefully defined. Then the original problem can be solved in terms of these data abstractions, after which the abstractions themselves can be programmed, perhaps in terms of still other abstractions. Each abstraction may be used without any knowledge of its implementation, and implemented without any knowledge of its use.
    For example, in writing a simple assembler the major data objects required are a source file, a partially assembled instruction file, a machine language file, and a symbol table. Once these four objects are described (as composites of simpler types), the operations upon them are defined and the relationships between them are understood, the control portion of the assembler can be written. Then the four data abstractions can he programmed independently. The programming process is performed via a sequence of refinements which continues until the objects and operations needed to define an abstraction are directly representable in the language being used.
    For this process to be carried out effectively, it is helpful if the programming language in use permits the programmer to implement each data object as a single syntactic unit (an encapsulation) that
    i) includes the definition of all required operations on the object
    ii) establishes a static scope for the data object so that it is preserved independent of the calls to the encapsulated operations
    iii) provides controlled access to the data object -- i.e. access only through the operations defined in the encapsulation.
    The languages listed earlier all provide such a facility in one form or another, but Pascal, as defined by Wirth unfortunately does not, The basic unit of modularity in Pascal, the procedure, does not provide direct access (as with multiple entry points) to more than one operation. The procedure also cannot provide a static scope for an object except as the object is declared global to all references, in which case all access control is lost. Although the process of refinement in terms of data abstractions may still be used to design and structure a program in Pascal, much of the pedagogic impact of this process is lost because the final program does not clearly reflect the design decisions made along the way.
    This is especially true when the programmers involved are students who are just learning to cope with problems of moderate complexity. Extract: The Capsule
    The Capsule
    To remedy this problem, we have extended the version of Pascal (University of Minnesota Pascal 6000, Release 3 [Mickel 79] in use at Temple University to include an encapsulation facility, called a capsule, having the properties i), ii), iii). The major features of the capsule are not new; the design is based primarily upon one implemention of the Euclid module and a modified version of the Concurrent Pascal class [Coleman 78]. The capsule is also similar to the envelope used in Pascal Plus [Welsh 80].
    Specifically, a capsule is an additional Pascal type which is syntactically similar in structure to the Pascal block.
    [...]
    The export list is a list of variable, procedure and function identifiers which may be referenced outside the scope of the capsule. All protection of the data objects encapsulated in the capsule is provided at compile time. Thus, if capstype is a capsule, and variable x is declared to be of type capstype, then all external references to identifiers, id, appearing in the export list for capstype must be of the form
    x$id
    Exported variables are read only, and identifiers not appearing in the export list may not be referenced outside the scope of the capsule. Work is currently in progress to implement an import facility to permit (in fact, require) the declaration within a capsule of all external objects referenced in capsule procedures, but not passed as arguments. This feature is expected to make it easier for programmers to access often-used external objects (especially different type capsule variables) without the added overhead of listing these objects in parameter lists. Modification of imported objects will not be permitted; such objects will have to be passed as arguments to the modifying procedures.
    The Pascal scope rules for capsules are the same as the rules for all other Pascal objects.
    [...]
    Only a single copy of the operations (procedures and functions) defined within a capsule is created, regardless of the number of variables declared to be of the capsule type. When a procedure (or function) containing the declaration of a capsule-type variable is called and the variable declaration is elaborated, the capsule's global variables are placed on the run-time stack as a record. This record remains on the stack as long as the called procedure (function) remains active. Operations on the abstract object are thus performed via calls of the appropriate capsule procedure or functions.
    Extract: Using Capsules
    Using Capsules
    Capsules are being introduced in two upper division undergraduate courses, CIS 223 and 324, being taught at Temple. CIS 223 is a second year programming course in which Pascal is first introduced and used to study searching, sorting, recursion~ and list and tree manipulation topics, such as those covered in Wirth's text Algorithms + Data Structures = Programs [Wirth 76]. Capsules are used in this course, most notably in the implementation of the simple assembler (described earlier). CIS 324 is a first course in compiler design. Here, students implement a compiler for a language, PL/CP [Friedman 79], that is ar extension of a simple subset of Pascal described in Wirth's text (Chapter 5). In this project, Capsules are used extensively both as an abstraction mechanism and as a means of eliminating some of the lower-level tasks required for implementing the compiler. These tasks, including basic list and stack manipulation algorithms have been coded and tested, and stored in generic, source form for general use in the capsule library. Students may include the source text of any of the available capsules in their compiler by using the generic specification illustrated in Figure 2.
    The capsule library facility is an unsophisticated adaptation of the CLU library concept [Liskov 77]. In CLU, each abstraction in the library can be represented by a description unit which contains the abstraction's interface specification; no implementations are necessary. Programs that reference an abstraction in the library may be completely compiled with complete type checking using just the interface information. Capsules currently provide no formal mechanism for separating the interface specification from the capsule implementation. As a result, a complete text copy of a capsule must be entered into the library, and this entire text (with parameter substitutions) is copied into a user's program at each request (via a generic specification).
    Still required as part of the project is an evaluation of the flexibility and utility of the capsule as a general-purpose abstraction tool, and an analysis of the impact of introducing the method of abstraction-based program refinement into the undergraduate curriculum.
    To facilitate these evaluations, we plan to expand the capsule library to provide a selection of capsules covering a wide variety of courses and applications areas. Unless the abstraction concept begins to permeate all aspects of computer science instruction, it will likely remain unused and unappreciated by most students. The application of the capsule facility must be taught early and often, for the concept of data abstraction is new to both faculty and students alike. Its effective use will require frequent opportunities for drill and practice, and a "new way of looking at problem solving using the computer." Extract: Future Considerations
    Future Considerations
    We have recently initiated an effort to validate the hypothesis that programming in a language that supports encapsulation leads to significant improvements in program quality. The recognition of the need for such validation is not new [see Shaw 78, for example]; not surprisingly, however, because of the inherent problems with such validation efforts [Shell 81], little work has been done in this area.
    We propose to examine previously validated quality measures at both the design (inter-module) level [Yin 78] and the implementation (intramodule) level [Halstead 77, McCabe 76, McCall 80]. We hope to be able to develop suitably controlled evaluations in terms of these measures of smallsized programming systems written in Pascal, both with and without the encapsulation feature. We believe that research on data abstraction techniques and the validation of software quality metrics has proceeded far enough for computer scientists to begin to demonstrate the validity of the hypothesis that the use of abstraction-based programming techniques tends to result in the production of higher quality software.
          in Proceedings of the ACM '81 conference view details