PS-ALGOL(ID:972/psa002)
Persistent Algol
Persistent Algol. ca 1981, released 1985. A derivative of S- Algol. Database capability derived from the longevity of data. Introduced the notion of a persistent programming language (where there exists a persistent store external to the running of each program)
IBM PC version available from CS Dept, U Strathclyde, Glasgow.
Structures:
Related languages
| NEPAL | => | PS-ALGOL | Evolution of | |
| S-Algol | => | PS-ALGOL | Evolution of | |
| PS-ALGOL | => | Napier | Evolution of | |
| PS-ALGOL | => | PCLOS | Incorporated some features of | |
| PS-ALGOL | => | POMS | Extension of |
References:
in SIGPLAN Notices 17(07) July 1982. view details
in Software — Practice and experience 13(07) March 1983 view details
in The Computer Journal 26(4) 1983 view details
in The Computer Journal 26(4) 1983 view details
in The Computer Journal 26(4) 1983 view details
in The Computer Journal 26(4) 1983 view details
in The Computer Journal 26(4) 1983 view details
in The Computer Journal 26(4) 1983 view details
in The Computer Journal 26(4) 1983 view details
in The Computer Journal 26(4) 1983 view details
in Proceedings of the Hawaii International Conference on System Sciences, January 1986 view details
in Kugler, H. J. (Ed.) Proceedings of IFIP, Dublin, Sept 1986 view details
in Kugler, H. J. (Ed.) Proceedings of IFIP, Dublin, Sept 1986 view details
in Data Types and Persistence. Atkinson, MP, Buneman, OP, Morrison, R (eds), Proc. 1st Workshop on Persistent Object Systems, Appin, Scotland, 1985. In Series: Topics in Information Systems. Springer-Verlag, ISBN 3-540-18785-5. 1988 view details
in SIGPLAN Notices 23(11) November 1988 (OOPSLA '88) view details
Introduction
CLOS (Persistent CommonLisp Object System) provides object persistence for an object-oriented language. It has been stable for some months now and several test applications have used it. While usage is not widespread enough to support substantial statistical observations, a large amount of insight has been gained on desirable and detrimental components. Some of these have been documented by various researchers, while others have not been reported formally.
While reference describes PCLOS itself, this review documents some triumphs and failures of the system. The intent is to draw attention to some obvious and to other more subtle problems in the context of object persistence. We do include difbculties that are specific to the current implementation. While these might not be fundamental to the concept of object persistence, they are often symptoms of problems whose solutions are conceptually simple but that are difficult to implement. Some other non-fundamental shortcomings can point out traps that can be avoided in other implementations. We hope to provide information that can be of use in the construction of any object persistence machinery.
PCLOS is used as a road map through the relevant issues.
The following section will provide a very quick overview of PCLOS. Each of the remaining sections then analyze one component of the system. In the first part of each section we generally explain the motivation and advantages of the component. This is then contrasted with descriptions of problems we encountered. Such problems include weaknesses in the implementation, fundamental technical problems and conceptual difficulties experienced by users. Extract: Outline of PCLOS
Outline of PCLOS
PCLOS stands for Persistent Common Lisp Object System. It provides persistence for objects in the Common Lisp Object System (CLOS). PCLOS is organized to allow the simultaneous use of multiple, different database management systems. [..] The language and program layer is insulated from differences among the databases by a virtual database. This implies the necessity of two mappings: objects and classes in the language layer must be described in terms of operations and concepts of the virtual database. The second mapping expresses the virtual database concepts and operations in terms of the various specific database managers.
The data model of the virtual database is 'relationesque' in the sense that it is based on virtual tables. The model is not fully relational because fields may reference rows in other tables. Each programming language class is conceptually represented by a table whose columns correspond to the slots? of the class and whose rows correspond to the class? instances. An object can therefore be uniquely specified by providing information about the database it resides in, the name of the appropriate virtual table and the virtual row number.
The mapping of the virtual tables onto database management systems obviously depends on the concepts and interface details of those systems.
The virtual database's model is just complex enough to accommodate the modelling needs of object-oriented languages. It is no more complex than this because it must be possible to implement it on very simple data stores. This design principle of minimal complexity is compromised by the desire to take advantage of very intelligent database management systems. An inflexible minimal virtual database model would preclude access of the language layer to such advanced capabilities.
PCLOS attempts to solve this problem by the notation of protocol adapters. Each of these adapters represents one database concept that is not represented by the virtual database?s core protocol. Examples are transaction management, database archiving or complex queries which provide existential quantifyers and multi-valued returns. Attempts to use these features on database systems that do not support the corresponding concept will cause a protocol mismatch error.
Objects move from databases into the language layer either because they are in the solution set of a query, or because a reference to them caused an object fault.
When an object is internalized in this way, PCLOS creates a husk object, an in-memory data structure representing the object for purposes of message dispatching and in-memory referencing. Slot accesses to husk objects are trapped and translated into updates or queries to the appropriate database. When an object is cached, its slot values are brought in from the database and are placed in the husk. From then on access to the object?s slots are handled lie accesses to non-persistent objects.
The remaining sections examine some details of this system. Additional information on PCLOS mechanisms will be introduced as needed. Extract: Language Integration
Language Integration
The term language integration is used here to describe the degree of naturalness and elegance with which database concepts are introduced into a programming language and to which extent persistence-related details are transparent to programmers.
The advantages of full language integration are rather obvious. Adding new capabilities to a computing environment leads to a cost-benefit analysis. The need to learn new concepts is a cost and should therefore be minimized.
A slightly more subtle point becomes apparent if we think about the alternatives to integration. These have generally been the introduction of embedded languages. With this technique all aspects of persistence are controlled through library calls and no attempt is made to assimilate persistence-related concepts into the language paradigm. One drawback of this solution is that the programmer must assume much more responsibility in a realm that is new to him. The larger number of control options alone tends to make systems with embedded languages more error prone than a more integrated system.
PCLOS language integration was accomplished through the use of the CLOS metaobject protocol. This mechanism is ideally suited to experiments in language integration.
It is based on the idea that after some bootstrapping, the object model of an object-oriented language can be implemented using that language itself. Employing the principles of object-oriented programming, the object model or its implementation may then be modified. The addition of persistence, for example, requires that all slot accesses be intercepted. PCLOS accomplishes this through the use of the metaobject protocol: the capabilities for representing and manipulating slots is inherited from the standard CLOS implementation.
The slot access methods alone are then shadowed by methods that add persistence-related behavior. Nevertheless, PCLOS suffers from a high number of transparency breaches. Some are a consequence of the specifics of the CLOS language, others are inherent problems of persistence. We outline some of these issues in the following subsections.
in SIGPLAN Notices 24(10) October 1989 incorporating the Proceedings of the Conference on Object Oriented Programming Systems Languages and Applications, New Orleans (OOPSLA 89) view details
in SIGPLAN Notices 24(10) October 1989 incorporating the Proceedings of the Conference on Object Oriented Programming Systems Languages and Applications, New Orleans (OOPSLA 89) view details
in SIGPLAN Notices 24(10) October 1989 incorporating the Proceedings of the Conference on Object Oriented Programming Systems Languages and Applications, New Orleans (OOPSLA 89) view details
in IEEE Transactions on Computers July 19, 1991 view details