| J.E. Richardson, M.J. Carey, and D.T. Schuh. The design of the E programming language. ACM Transactions on Programming Languages and Systems, 15(3):494--534, July 1993. |
....construction and maintenance. The preceding languages, while valuable research vehicles, did not appeal to commercial and industrial application builders because they were unfamiliar. In contrast, persistent languages based on C and C have the advantage of familiarity. Examples are: E [181] and O [2, 1] These languages also failed to lead to full evaluations of persistence. We suspect that this is because the weak control of pointers in C meant that they were never able to become sufficiently simple and robust. Persistent extensions to Pascal [49, 48] only became available as ....
J.E. Richardson, M.J. Carey, and D.T. Schuh. The design of the E programming language. ACM Transactions on Programming Languages and Systems, 15(3):494--534, July 1993.
....Node Types In the original Ariel system, since a variation of TREAT was used, there were no fi nodes, only ff nodes and P nodes. There were seven different types of ff nodes with slightly different behavior (see [4] for details) These were implemented as a hierarchy of classes in the E language [17], a form of persistent C . Memory nodes in Ariel can be either static, in which case their contents are persistent and are stored between transactions, or dynamic, in which case they are flushed after each transaction. To implement Gator, the memory node class hierarchy was modified to include ....
Joel E. Richardson, Michael J. Carey, and Daniel T. Schuh. The design of the E programming language. ACM Transactions on Programming Languages and Systems, 15(3), 1993.
....general guideline is to provide users with a system of much flexibility yet is easy to use. Our development strategies are the following. 2.1 No modification to user code We want the object I O facility to be as simple as possible. In particular, no extension to C language will be considered [9]. Nor do we consider to force the class in need of object I O to be derived from some object I O base class (since this will change the existing hierarchical structure in user s class library) 8] We want to provide a class based facility for object I O, modeled after the C stream I O facility ....
Joel E. Richardson, Michael J. Carey, and Daniel T. Schuh. The design of the E programming language. ACM Transaction on Programming Languages and Systems, 15(3):494--534, July 1993.
....method typing, the absence of reflexivity and schema evolution, single dispatch, and very limited parametricity. One of its strengths, of course, is its close relationship with C ; however, in terms of its type system O is rather limited. Another database programming language based on C is E [RCS93] It improves the handling of parametric types, but otherwise inherits the same C drawbacks as O . Completely different approach was taken in CLOS [BDG 88] CLOS is reflexive and has multiple dispatch; however, it lacks static type checking. Dylan [App94] is more recent language based (to ....
Joel E. Richardson, Michael J. Carey, and Daniel T. Schuh, The design of the E programming language, ACM Transactions on Programming Languages and Systems 15 (1993), no. 3, 494--534.
....Object unmapping is easier because references are indirect. When an object is unmapped it is only necessary to update its pidlam entry to allow future faults on the object to be detected. 1. 2 E Persistent Types, Object Fault Avoidance, and No Swizzling The E persistent programming language [47] was developed as one part of the Exodus extensible database management system project [19] at the University of Wisconsin at Madison. E, a persistent extension of C , was originally conceived as a language in which database system code could be written but was developed as a general purpose ....
....any db type may however exist. E provides a collection of fundamental db types, such as dbint and dbchar, and db type constructors, such as dbclass and dbstruct, as well as pointers to db types and arrays of db types. Any type that can be defined in C can be analogously defined as a db type [47]. If a variable of a db type is declared to have the storage class persistent, the object bound to that variable will persist. Thus, the names of such variables act as handles for objects in the persistent store. An E program may also create persistent objects dynamically using the predefined ....
Joel E. Richardson, Michael J. Carey, and Daniel T. Schuh. The design of the E programming language. ACM Transactions on Programming Languages and Systems, 15(3):494--534, July 1993.
....Kernel) interpreter, which processes the datadefinition language (DDL) and imperative data manipulation language (DML) of the system. 3. The ROLL (for Rule Object Logic Language) interpreter, which processes the deductive query language (DQL) of the system. The OM is written in E [4] over EXODUS [12] (as are the two other software components of ROCK ROLL) and its main function is to provide a unified view of the structures and behaviours definable in ROCK ROLL to both the ROCK and the ROLL interpreters. As a DDL, ROCK provides a set of primitive types with which complex ....
.... to go beyond the intuitive meaning conveyed by an operation s name and signature is advised to consult [8, 9] the Modula 2 implementation described in [7] or the implementation described in [11] which was carried out in the same software environment as the ROCK ROLL system, i.e. EXODUS E [4, 12]. 6.1 Equality of SVs Two SVs are equal iff their constituent elements are equal, i.e. SV equality is set equality. It is part of the layered definition of the ROSE algebra that the formal definition of equality for entities in one layer relies on the equality predicate for the entities in the ....
Joel E. Richardson, Michael J. Carey, and Daniel T. Schuh. The Design of the E Programming Language. ACM Transactions on Programming Languages and Systems, 15(3):494--534, July 1993.
....it applies a local change operator. This is an inefficient way to move from one state to another. An alternative is to directly modify the data structure representing the state to move it to the next state, and to undo these changes if they are not beneficial. Moreover, the Exodus eg compiler [20], an unsupported compiler that is not of commercial quality, was used. The Gator network data structures were implemented using dbclasses [20] rather than regular C classes, further slowing optimizer performance, since dereferencing a pointer to a dbclass object takes many instructions instead ....
....structure representing the state to move it to the next state, and to undo these changes if they are not beneficial. Moreover, the Exodus eg compiler [20] an unsupported compiler that is not of commercial quality, was used. The Gator network data structures were implemented using dbclasses [20] rather than regular C classes, further slowing optimizer performance, since dereferencing a pointer to a dbclass object takes many instructions instead of one. The E compiler was used to reduce total coding effort, since the Gator networks must be made persistent, and dbclasses provided ....
J. E. Richardson, M. J. Carey, and D. T. Schuh. The design of the E programming language. ACM Transactions on Programming Languages and Systems, 15(3), 1993.
....the design does not guarantee the integrity of persistent data. 5.1 Persistent Types The key to persistent Ada95b is the notion that types can have the property of persistency; i.e. the property that values of the type may potentially persist beyond a program execution. We follow the precedent of [15] and [21] and classify types as either persistent types or non persistent types according to whether or not they have this property 3 . Note that objects of a persistent type may persist depending on their reachability. Conversely, objects of a nonpersistent type can not persist. All types in ....
J. Richardson, M. Carey, and D. Schuh. The design of the E programming language. ACM Transactions on Programming Languages and Systems, 15(3):494-- 534, July 1993.
....i.e. heap garbage collection is not an absolute requirement. 6.1 Persistent Types The basis of persistent Ada95 is the notion that types can have the property of persistency; i.e. the property that values of the type may potentially persist beyond a program execution. We follow the precedent of [30] and[39] and classify types as either persistent types or non persistent types according to whether or not they have this property 7 . Note that the term persistent type 7 This terminology is somewhat misleading in that it seems to suggest that the types themselves are persistent objects. ....
J. Richardson, M. Carey, and D. Schuh. The design of the E programming language. ACM Transactions on Programming Languages and Systems, 15(3):494-- 534, July 1993.
....chunk of uninterpreted data called a storage object through a unique identifier called an OID. The Storage Manager supports concurrency control through two phase locking, and a simple transaction facility with full recovery from hardware and software failures. The E programming language [43] is an extension of C that supports persistent data data that retains its state between runs of a program. E syntax extends C with a db version of each primitive type and type constructor (e.g. dbint, dbclassf. g, etc. Instances of a db type can be allocated from a persistent heap. ....
Joel Richardson, Michael Carey, and Daniel Schuh. The design of the E programming language. ACM Transactions on Programming Languages and Systems, 15(3), July 1993.
....OO7 As an initial step towards filling the information gap that the introduction mentioned in the area of multiuser OODBMS performance characteristics, we are currently developing a multi user OO7 OODBMS benchmark. There are five systems currently involved in this effort: E Exodus [CDF 86, RCS93] O2 [Deu91] Objectivity [Obj92] Ontos [Ont92] and Versant [Ver92] Our experience so far is that designing a multiuser benchmark is a much more difficult problem than designing a single user benchmark. This is partially due to the fact that the number of dimensions along which the workload ....
Joel E. Richardson, Michael J. Carey, and Daniel T. Schuh. The design of the E programming language. ACM Transactions on Programming Languages and Systems, 15(3), July 1993.
....query optimization model. Extending Java with powerful reflective capabilities raises several issues. We discuss these issues in Section 7 and conclude in Section 8. 2 Related work The work presented in this paper relates to work on implementing persistent programming languages, for example, E [Richardson et al. 1993], Persistent Smalltalk [Hosking, 1995] PJama [Atkinson et al. 1996] etc. Our work differs from all the above in that it applies a new technique to implement persistence, namely reflection. None of the persistent programming languages above support query optimization. Stemple, et al. Stemple et ....
Joel E. Richardson, Michael J. Carey, and David T. Schuh. The Design of the E programming Language. ACM Transactions on Programming Languages and Systems 15, 3 (July 1993), 494--534.
No context found.
J.E. Richardson, M.J. Carey, and D.T. Schuh. The design of the E programming language. ACM Transactions on Programming Languages and Systems, 15(3):494--534, July 1993.
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