Path Pascal(ID:922/pat005)Parallel extension of Pascal. Processes have shared access to data objects. Constraints on their synchronization are specified in a path expression. Structures: Related languages
References: in Proc. Programming Syraposium, Paris 1974, edited by, G. Goos and J. Hartmanis, Springer- Verlag, New York (1974). view details in Proc. Programming Syraposium, Paris 1974, edited by, G. Goos and J. Hartmanis, Springer- Verlag, New York (1974). view details in Proc. Programming Syraposium, Paris 1974, edited by, G. Goos and J. Hartmanis, Springer- Verlag, New York (1974). view details in Proc. Programming Syraposium, Paris 1974, edited by, G. Goos and J. Hartmanis, Springer- Verlag, New York (1974). view details in Proc. Programming Syraposium, Paris 1974, edited by, G. Goos and J. Hartmanis, Springer- Verlag, New York (1974). view details DOI in [ACM SIGACT-SIGPLAN] Proceedings of the 6th Annual ACM Symposium on Principles of Programming Languages, San Antonio, Texas view details in Proceedings of the 4th International Conference on Software Engineering 1979, Munich, Germany view details in Proceedings of the 4th International Conference on Software Engineering 1979, Munich, Germany view details Path Expressions were introduced as a technique for specifying process synchronization by [Campbell & Habermann, 74], and further discussed by [Habermann, 75], [Lauer & Campbell, 75], [Flon & Habermann, 76], [Andler, 79] and [Campbell, 77]. Variations of the Path Expression idea have been proposed by [ONERA CERT, 77] and notations that are similar to paths that model system behavior have been developed independently by [Shaw, 77] and [Riddle, 76]. A specification language has also been designed [Lauer & Shields, 78] based upon the use of a Path Expression notation. Path Pascal Is based on the P4 subset of Pascal [Ammann, et al., 76] (see Appendix F for a summary of the P4 subset). The Path Pascal compiler is written in Pascal P4 and accepts any Pascal P4 program that does not use Path Pascal reserved words as identifiers. Pascal was aug-•ented with an encapsulation mechanism (see chapter 2), Open Path Expressions [Campbell, 77] (see chapter 3), and a process mechanism (see chapter 4). Open Paths are integrated with the encapsulation mechanism to enforce a strict discipline upon the programmer to describe shared data objects. All access to encapsulated data is performed by operations synchronized by Open Paths. A process invoking such operations may execute the operation only if permitted by the Open Path Expression associated with the shared data object. The following chapters describe Path Pascal IB s»re detail. Motivations for the design of Path Pascal are discussed further in [Miller, 78], raspbell & Kolstad, 79a], [Campbell & Kolstad, 7%), [Campbell & Kolstad, 80], [Horton & Campbell, €-1, and [Kolstad & Campbell, 80]. A description of Pascal can be found in the Pascal Report [Jensen & Wlrth, 75]. The additional Path Pascal syntax is listed in Appendix A. Appendix B contains error •essages, control options and constants for the Fm^a Pascal P code interpreter. Appendix C describes the semantics of Open Path Expressions in t«rw of P and V operations. Appendix D contains •s**rsl saaple programs. Appendix E describes the c - 6e* that have been made to the intermedlate €*4s (?-Code) for the additional Path Pascal constructs. Appendix F summarizes the differences in Proceedings of the 4th International Conference on Software Engineering 1979, Munich, Germany view details in Proceedings of the 4th International Conference on Software Engineering 1979, Munich, Germany view details in Proceedings of the 4th International Conference on Software Engineering 1979, Munich, Germany view details in SIGPLAN Notices 15(09) September 1980 view details in SIGPLAN Notices 15(09) September 1980 view details Path Expressions were introduced as a technique for specifying process synchronization by [Campbell & Habermann, 74], and further discussed by Habermann, 75], [Lauer & Campbell, 75], [Flon& Habermann, 76], [Andler, 79] and [Campbell, 77]. Variations of the Path Expression idea have been proposed by [ONERA CERT, 77] and notations that are similar to paths that model system behavior have been developed independently by [Shaw, 77] and [Riddle, 76]. A specification language has also been designed [Lauer & Shields, 78] based upon the use of a Path Expression notation. Path Pascal is based on the P4 subset of Pascal [Ammann, et al., 76] (see Appendix F for a summary of the P4 subset). The Path Pascal compiler is written in Pascal P4 and accepts any Pascal P4 program that does not use Path Pascal reserved words as identifiers. Pascal was augmented with an encapsulation mechanism (see chapter 2), Open Path Expressions [Campbell, 77] (see chapter 3), and a process mechanism (see chapter 4). Open Paths are integrated with the encapsulation mechanism to enforce a strict discipline upon the programmer to describe shared data objects. All access to encapsulated data is performed by operations synchronized by Open Paths. A process invoking such operations may execute the operation only if permitted by the Open Path Expression associated with the shared data object. The following chapters describe Path Pascal In more detail. Motivations for the design of Path Pascal are discussed further in [Miller, 78], [Campbell & Kolstad, 79a], [Campbell & Kolstad, 79b], [Campbell & Kolstad, 80], [Horton & Campbell, 80], and [Kolstad & Campbell, 80]. A description of Pascal can be found in the Pascal Report [Jensen & Wirth, 75]. The additional Path Pascal syntax is listed in Appendix A. Appendix B contains error messages, control options and constants for the Path Pascal P code interpreter. Appendix C describes the semantics of Open Path Expressions in terms of P and V operations. Appendix D contains several sample programs. Appendix E describes the changes that have been made to the intermediate code (P-Code) for the additional Path Pascal constructs. Appendix F summarizes the differences between Path Pascal and Pascal P4. in SIGPLAN Notices 15(09) September 1980 view details Introduction It is widely acknowledged that producing correct software is both difficult and expensive. To help remedy this situation, methods of specifying and verifying software have been developed. The SAGA (Software Automation, Generation and Administration) project is investigating both the for real and practical aspects of providing automated support for the full range of software engineering activities. PLEASE is a language being developed by the SAGA group to support the specification, prototyping, and rigorous development of software components. In this paper we describe the development methodology for which PLEASE was created, give an example of development using the language, and describe the methods used to prototype PLEASE specifications. A life-cycle model describes the sequence of distinct stages through which a software product passes during its lifetime. There is no single, universally accepted model of the software life-cycle. The stages of the life-cycle generate software components, such as code written in programming languages, test data or results, and many types of documentation. In many models, a specification of the system to be built is created early in the lit%-cycle; as components are produced they are verified for correctness with respect to this specification. The specification is validated when it is shown to satisfy the customers requirements. Producing a valid specification is a difficult task. The users of the system may not really know what they want, and they may be unable to communicate their desires to the development team. If the specification is in a formal notation it may be an ineffective medium for communication with the customers, but natural language specifications are notoriously ambiguous and incomplete. Prototyping and the use of executable specification languages have been suggested as partial solutions to these problems. Providing the customers with prototypes for experimentation and evaluation early in the development process may increase customer/developer communication and enhance the validation and design processes. To help manage the complexity of software design and development, methodologies which combine standard representations, intellectual disciplines, and well defined techniques have been proposed. For example, it has been suggested that top-down development can help control the complexity of ~ program construction. By using stepwise refinement to create a concrete implementation from an abstract specification we divide the decisions necessary into smaller, more comprehensible groups. Methods to support the top-down development of programs have been devised and put into use. It has also been proposed that software development may be viewed as a sequence of transformations between specifications written at different linguistic levels; systems to support similar development methodologies have been constructed. Extract: VDM and PLEASE The Vienna Development Method supports the top-down development of programs specified in a notation suitable for mathematical verification. In this method, programs are first written in a language combining elements from conventional programming languages and mathematics. A procedure or function may be specified using pre and post-conditions written in predicate logic; similarly, an invariant ,nay be specified for a data type. Then these abstract programs are incrementally refined into programs in an implementation language. The refinements are performed one at a time, and each is verified before another is applied; therefore, the final program produced by the development satisfies the original specification. Extract: Path Pascal and PLEASE Path Pascal is an extension to standard Pascal allowing concurrent programming and encapsulated data types. In Path Pascal, a process is a program structure which has an independent thread of execution; independently executing processes communicate through shared data structures. Encapsulated data types called objects are manipulated only by the predefined routines associated with the type. Path expressions specify synchronization constraints that apply to the execution of the processes, functions and procedures within objects. Extract: about PLEASE PLEASE is an extension of Path Pascal, which supports a methodology similar to the Vienna Development Method. In PLEASE, a procedure or function may be specified with pre- and post-conditions written in predicate logic, and similarly an object may be specified using an invariant. For ease of expression, several data types have been added to the language. PLEASE specifications may be used in proofs of correctness; they also may be transformed into prototypes which use Prolog to "execute" pre- and post conditions, and may interact with other modules written in conventional languages. We believe that the early production of executable prototypes for experimentation and evaluation will enhance the software development process. Extract: Plan In section two of this paper, we describe the development methodology PLEASE was designed to support, and in section three, we give an example of program development using PLEASE. First we discuss an example program specification and describe how an executable prototype could be created for it. Then we show a refinement of this specification and discuss the process of verifying that the refined specification satisfies the original. In section four, we give an example of data type specification in PLEASE, and in section five, we discuss the implementation of the system, in section six, we describe tile work we have planned for the future and in section seven, we summarize and draw some conclusions from our experience. in SIGPLAN Notices 15(09) September 1980 view details in SIGPLAN Notices 15(09) September 1980 view details in SIGPLAN Notices 15(09) September 1980 view details External link: Online copy in Vowels, R. A. Introduction to PL/I, Algorithms, and Structured Programming , 3rd Ed., Sept. 1997, ISBN 0-9596384-9-0. view details |