M.P.Atkinson, P.J.Bailey, K.J.Chisholm, W.P.Cockshott, R.Morrison: An approach to persistent programming, Computer Journal 26(4), November 1983.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....is the correct framework within which to study and carry out such unification. In this framework we can analyze existing integrated data oriented systems and to design better ones. A nice step in unifying data models and type systems was the introduction of orthogonal persistence of data [Atkinson Bailey Chisholm Cockshott Morrison 83] which bridges the gap between ephemeral Page 2 (programming language) and persistent (information system) data. But this is not sufficient; it has become increasingly evident that data models aim to be more expressive than ordinary type systems, and that the nature of information systems ....

M.P.Atkinson, P.J.Bailey, K.J.Chisholm, W.P.Cockshott, R.Morrison: An approach to persistent programming, Computer Journal 26(4), November 1983.

....became the most prominent data model, giving rise to persistency models for languages like Smalltalk 80, Trellis Owl, CLOS, C , BETA, etc. The notion of persistency originates from the work on PS ALGOL, which is a milestone in the development of concepts for persistence in programming languages [ABC83]. It is outside the scope of this report to give a full account for the research in persistence in programming languages. Interested readers may find a more detailed account in Part I of [AFO89] We will in the following give a short introduction to the most important issues (mostly taken from ....

....in secondary storage. The application programmer has to develop and maintain two representation of the application model, and keep these representations consistent, despite the possible incompatibilities of the two data models. The implementation of these mappings adds to the complexity and in [ABC83] it is reported, that experiences shows that typically 30 of the code in an application program is concerned with transferring and mapping objects. 7.2 PERSISTENT VS. TRANSIENT DATA Persistence is an aspect of object lifetime. We define thelifetime of an object as the span of time from its ....

M.P. Atkinson, P.J. Bailey, K.J. Chrisholm, P.W. Cockshott, R. Morrison: An approach to persistent programming,The Computer Journal, 26(4), 983.

....in this section. Page 49 9.1. Dynamic types Static typechecking cannot cover all situations. One problem is with giving a type to an eval function, or to a generic print function. A more common problem is handling in a type sound way data that lives longer than any activation of the compiler [Atkinson Bailey Chisholm Cockshott Morrison 83] These problems can be solved by the introduction of dynamic types, here realized by a built in module dynamic:Dynamic (see the Appendix) Objects of type Dynamic T should be imagined as pairs of a type and an object of that type. In fact, Dynamic T is defined as the type Auto A: TYPE with a:A ....

M.P.Atkinson, P.J.Bailey, K.J.Chisholm, W.P.Cockshott, R.Morrison: An approach to persistent programming, Computer Journal 26(4), November 1983.

....structures. Moreover, persistent data are strongly typed, so that a type error is generated (at run time) if one happens to import the wrong kind of object. A limitation is that one can only import export whole objects; hopefully a scheme will be found to store partial objects, along the lines of [Atkinson Bailey Chisholm Cockshott Morrison 83] At the implementation level, the Amber system is organized in three layers. At the bottom there is a kernel which provides input output, graphics, heap management and (in the future) process scheduling. Heap management consists of data allocation, collection and persistent storage. This level ....

M.P.Atkinson, P.J.Bailey, K.J.Chisholm, W.P.Cockshott, R.Morrison: An approach to persistent programming, Computer Journal 26(4), November 1983.

....so this store also promises to offer reasonable efficiency levels. Our high level design is based on the premise of explicit persistence. Having explicitly marked an object as persistent, it follows that all objects reachable from it will persist automatically. Thus orthogonal persistence [3] is maintained while retaining the ability to mark selected objects as persistent explicitly. This helps avoid the time and space performance penalties that can arise with implicit persistence through saving unwanted intermediate values. Our objective is to allow programmers to implement ....

M.P. Atkinson, P. Bailey, K.J. Chisholm, W.P. Cockshott and R. Morrison An Approach to Persistent Programming, Computer Journal, Vol. 26, No.4, 1983, pp. 360--365.

No context found.

M.P.Atkinson, P.J.Bailey, K.J.Chisholm, W.P.Cockshott, R.Morrison: An approach to persistent programming, Computer Journal 26(4), November 1983.

No context found.

M.P.Atkinson, P.J.Bailey, K.J.Chisholm, W.P.Cockshott, R.Morrison: An approach to persistent programming, Computer Journal 26(4), November 1983.

No context found.

M.P.Atkinson, P.J.Bailey, K.J.Chisholm, W.P.Cockshott, R.Morrison: An approach to persistent programming, Computer Journal 26(4), November 1983.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC