Bobrow, B.; DeMichiel, D.; Gabriel, R.; Keene, S.; Kiczales, G.; ; and Moon, D. 1988. Common lisp object system specification. Technical Report 88-002R, X3J13.  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... INTEGER integerlnChildOne; PROCEDURE Print; OutInt(integerInChildOne, OutImage; integerInChildOne : 17; Parent CLASS ChildTwo; BOOLEAN booleanlnChildTwo; booleanInChildTwo = FALSE; PROCEDURE Assign(arg) REF(Parent) ARRAY arg; arg[1] NEW Parent; arg [2] NEW ChildOne; arg [3] : NEW ChildTwo; END; 20) Figure 1.0. Declarations for a type unsafe SIMULA program have only one attribute, a boolean initialized to FALSE. We have thus created a very simple type hierarchy, shown in Figure 1.0. The procedure Assign, also in Figure 1.0, is the key to the example. It takes ....

....the PLEAT specific parts of these mechanisms by the appropriate counterparts for any other language with a notion of subtyping. For example, the same techniques could be applied to a language with a complex hierarchy of predefined types; the object oriented extension to Common Lisp comes to mind [22,3]. We have begun work on the application of these ideas to the programming language Scheme [19] Expressive power. We have demonstrated our ability to give types to many pro grams that make extensive use of both polymorphism and subtyping. Not only can constrained quantification express sound, ....

Bobrow, Daniel G., DeMichiel, Linda G., Gabriel, Richard P., Keene, Sonya E., Kiczales, Gregor, and Moon, David A., Common Lisp Object System Specification, SIGPLAN Notices, v. 23, Special Issue, September 1988.

....as they implement compatible methods. This is referred to as structural conformance (e.g. Smalltalk 80, 5] Methods on instances can be wrapped by other methods; that is, the programmer can define methods that are executed before and or after a method of the target instance. e.g. CLOS, [1]) Method calls on one object can be delegated to another object (e.g. Objective C, 11] Instances can be created of classes that mix multiple parent classes dynamically (e.g. CLOS, 1] These and similar constructs do not exist in standard Java. There have been suggestions for ....

....define methods that are executed before and or after a method of the target instance. e.g. CLOS, 1] Method calls on one object can be delegated to another object (e.g. Objective C, 11] Instances can be created of classes that mix multiple parent classes dynamically (e.g. CLOS, [1]) These and similar constructs do not exist in standard Java. There have been suggestions for implementing some of these facilities by using preprocessing or compilation techniques or modifications to the Java runtime. For example, Laufer et al. 10] propose a method for implementing safe ....

D.G. Bobrow, L.G. DeMichiel, R.P. Gabriel, S.E. Keene, G. Kiczales, and D.A. Moon. Common lisp object system specification. i. programmer interface concepts. LISP and Symbolic Computation, 1(3-4):245--98, 1989.

....The program in Figure 1 can be considered a first naive attempt to capture inheritance with datalog . The rule employee(X) wstudent(X) tries to capture inheritance: the classes with extensions working students and employees are such that the former class is a subclass of the latter. A closer look at the rules defining the salary and socins predicates reveals that, because the predicates employee(X) and wstudent(X) appear in the body of the respective rules, each rule could be considered as applicable only to the corresponding classes. Now observe that since each working student is ....

....in Delta, there is exactly one ground fact c(o) in Delta. The class c is called the base class of an object o, if fact c(o) is in Delta. This is in the spirit of the oid assignment of IQL [AK89] The following notions to deal with the class hierarchy will be used. Let the transitive reflexive closure of . The set of all super and subclasses of a given class name c is defined as c j c c g, and c j c cg, respectively. Let D C be a set of class names. The subset of minimal (maximal) classes (with respect to ) in D is denoted D (D ) 2.4 Semantics of datalog by ....

[Article contains additional citation context not shown here]

D. G. Bobrow, L. Demichael, R. P. Gabriel, S. Keene, G. Kiczales, D. Moon. Common Lisp Object System Specification. In SIGPLAN Notice, vol. 23 Special issue, sept. 1988.

....Model for OO Early in the development of Object Oriented Programming Models, another alternative also contended for consideration by language designers. This Generic Function Model , was adopted primarily by LISP based programming languages, notably, the Common Lisp Object System (CLOS)[1], and, more recently, the Cecil Research Report for early dissemination of its contents. In view of the transfer of copyright to the outside publisher, its distribution outside of IBM prior to publication should be limited to peer communications and specific requests. After outside publication, ....

Daniel Bobrow, Linda DeMichiel, Richard Gabriel, Sonya Keene, Gregor Kiczales, David Moon, Common Lisp Object System Specification, SIGPLAN Notices Vol 23 September 1988, pp.1-11

....accepted formal basis for the study of modern type systems. Like G [13] Tr is intended for apphcation programming and for system program ming tasks. By virtue of its polymorphic type system TL can also be utihzed as a data modehng language. In this respect, Tr resembles Lisp development systems [3] and commercial object oriented languages hke Smalltalk [9] From integrated database programming languages hke PS Algol [2] Napier88 (see Chapter 1.1.3) Amber [4] and P Quest, mentioned before, Tycoon inherits the orthogonahty of elementary kernel concepts for persistence abstraction, ....

D.C. Bobrow, L.G. De Michiel, R.P. Gabriel, S.E. Keene, G. Kiczales, and D.A. Moon. Common lisp object system specification. ACM SICPLAN Notices, 23, September 1988.

....methods of an object. For instance some methods may need to be executed in mu tual exclusion or may need to be ordered to ensure the coherence of some instance variables. This level is similar to the meta level of reflective languages and metaobject protocols (e.g. Open C [9] ACT [16] CLOS [6], or ABCL R [27] An object state is a mapping from the set of instance variables to a set of values. A transition between two object states is associated with a synchronized method. A group behavior factorizes several object behaviors. So the object model is a particular refinement of the group ....

D.G. Bobrow, L.G. DeMichiel, R.P. Babriel, S. Keene, G. Kiczales, and D.A. Moon. Common lisp object system specification. ACM SIGPLAN Notices, 23, September 1988.

....Java [1, 13] have both inspired this work as a metaphor and provided solid implementation advice. Like Smalltalk and Self, and unlike Java, we fully represent the modeling language using the system s own capabilities. The architecture of the virtual machine, however, probably owes most to CLOS [2, 21, 5]. CLOS simple yet elegant metalevel architecture directly influenced how we extend UML with M1 and M3 level classes to turn the logical model into a reflective system. We share Brian Foote s conviction that a system should be built on flexible foundations in the form of open languages, ....

Daniel G. Bobrow, Linda G. DeMichiel, Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales, and David A. Moon. "Common Lisp Object System Specification." SIGPLAN Notices, 23 (Special Issue), September 1988.

....a server database management system (DBMS) Now, the reflection, defined in [2] as the ability for a program to manipulate as data something representing its state during its own execution, and the reflection paradigm [3, 7, 19] have become a major issue for system definition. Languages and tools [1, 8, 9] have widened the use of reflection. So client persistent applications may be built using a reflective programming language or be themselves reflective. Moreover, adding reflective properties to DBMSs appears to be very promising: it helps to adapt the DBMS data model, that is, the formalism in ....

D. Bobrow, L. DeMichiel, R. Gabriel, S. Keene, G. Kiczales and D. Moon, Common Lisp Object System Specification, SIGPLAN notices 23 (special issue), 1988

....the multiple inheritance mechanism in Flavors, mixin classes allow a more dynamic, applicative style of object oriented programming where classes are modified and refined by having new features mixed in to them. Mixin inheritance has since been incorporated into the CLOS extension to Common Lisp [Steele1984, Bobrow1988]. A number of authors have written of the virtues of this style of programming [Hendler1986, Wolf1989, Bretthauer1990] but the lack of an abstract explanation of the technique has led to its use being primarily in Flavors and other dialects of Lisp which support it directly. Previous work has ....

David G. Bobrow, Linda G. DeMichiel, Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales and David A. Moon, "Common Lisp Object System Specification", X3J13 Document 88-002R, June 1988. Also appears as SIGPLAN Notices Vol. 23, Special Issue, September 1988.

....same for M n ; n 0. Such features cannot be extended and may be said to be intransigent. An OOPL can be reflective whilst still having intransigent features; an OOPL which has no intransigent features may be said to be fully reflective. Reflective OOPLs include Smalltalk [19] Loops [4] CLOS [3] [24] KRS [34] ObjVLisp [13] 5] 6] These languages differ in terms of the ways in which the golden braid is implemented and the extent to which it may be used to affect the basic interpretive mechanisms of the respective languages. This paper describes the reflective power of Smalltalk, ....

Bobrow D. et al. Common Lisp Object System Specification. Lisp and Symbolic Computation 1, 3/4. (Jan. 1989)

....design choices were made can be found in the EuLisp rationale. EuLisp breaks with LISP tradition in describing all its types (in fact, classes) in terms of an object system. This is called The EuLisp Object System, or TELOS. TELOS incorporates elements of the Common Lisp Object System (CLOS) [2], ObjVLisp [7] Oaklisp [9] MicroCeyx [5] and MCS [3] 1.1. Language Structure The EuLisp definition comprises the following items: Level 0 comprises all the level 0 functions, macros and special forms, which is this text minus Annex B. The object system can be extended by user defined ....

Bobrow, D.G., DeMichiel, L.G., Gabriel, R.P., Keene, S.E, Kiczales, G., and Moon, D.A. Common Lisp Object System Specification. SIGPLAN Notices, 23, 9 (September 1988).

.... on the language Smalltalk (Goldberg and Robson 1983) Harris Corporation has developed a language for their internal use called InnovAda (Simonian and Crone 1988) that is based on Flavors (Moon 1986) an object oriented extension to Lisp that has been made obsolete by the Common Lisp Object System (Bobrow et al. 1988)) Several other approaches have been described also (Forestier, Fornarino, and Franchi Zannettacci 1989; Winkler 1990) The most widely praised Ada extension (Johnson 1990) is the programming language Distributable Reusable Ada Generated from an Object Oriented Notation (DRAGOON) Di Maio et al. ....

Bobrow, Daniel G.; DeMichiel, Linda G.; Gabriel, Richard P.; Keene, Sonya E.; Kiczales, Gregor; and Moon, David A. 1988: Common Lisp Object System Specification. SIGPLAN Not., vol. 23, Special Issue, pp. 1-1--1-48.

.... database systems have been or are being developed, examples of which are GemStone [Maier et al. 1986] Orion [Banerjee et al. 1987] and Iris [Fishman et al. 1987] For programming languages there are Smalltalk [Goldberg and Robson, 1983] Trellis 1 [Schaffert et al. 1986] and CLOS [Bobrow et al. 1988], among many others. Integration efforts can build on the experiences of both the database and programming language worlds. More significantly, object orientation provides encapsulation of data and operations in such a way as to enhance the reusability, maintainability, and extensibility of ....

Daniel G. Bobrow, Linda G. DeMichiel, Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales, and David A. Moon. Common Lisp object system specification. ACM SIGPLAN Notices 23, special issue (September 1988). ANSI X3J13 Document 88-002R.

....by the object transportation. operation void check( traverse from Program via Stmt to Id carry in DecList env = declList ) declList is a part of Program that holds declarations along from Program to Id wrapper Id prefix ( check whether the id is in declList ) CLOS [7] also uses before and after concepts which sound similar to the prefix and suffix wrappers. But before and after have different meanings in CLOS than prefix and suffix in propagation patterns. With propagation patterns, a prefix wrapper is physically concatenated with the corresponding traversal ....

D.G. Bobrow, L.G. DeMichiel, R.P. Gabriel, S.E. Keene, G. Kiczales, and D.A. Moon. Common Lisp Object System Specification. SIGPLAN Notices, 23, September 1988. 180 BIBLIOGRAPHY 181

....the ground up. Another important area for exploration is the space of different kinds of component and aspect language designs. Can we develop a collection of component and aspect languages that can be plugged together in different ways for different applications Can we use meta level frameworks [2, 3, 20, 38] to build such a collection What theoretical support can be developed for AOP What kinds of theories can best describe the interaction between aspects and components and how they must be woven Can such theories support development of a practical weaving toolkit What about the analysis and ....

Bobrow D. G., DeMichiel L. G., et al., Common Lisp Object System Specification, in SIGPLAN Notices, vol. 23, 1988.

....have a specially designated target argument, sometimes called receiver, whose type, determined either at runtime or at compile time, serves to select the method to execute in response to a function invocation. Multiple dispatching, first introduced in CommonLoops [Bobrow et al. 1986] and CLOS [Bobrow et al. 1988], generalizes this form of dynamic binding by selecting a method depending on the run time type of a subset of the arguments of a function invocation. Methods in this generalized scheme are called This work was done while the authors were at INRIA. Author s address: E. Dujardin, SunSoft, Embedded ....

....1992] We generalized this notion for method orders in the above definition. Languages such as Cecil [Chambers 1993] and Dylan [Barrett et al. 1996] use a precedence ordering that satisfies the monotonicity condition. This will be formally stated in Section 4 of the paper. On the contrary, CLOS [Bobrow et al. 1988] does not enforce monotonicity. However, Ducournau et al. 1994] proposes a monotonous class precedence order that would yield a monotonous order on methods. Submitted to the ACM Transactions on Programming Languages and Systems 6 Delta Eric Dujardin et al. Fig. 3. Example Schema H m 1 (A; B) m ....

Bobrow, D. G., DeMichiel, L. G., Gabriel, R. P., Keene, S., Kiczales, G., and Moon, D. A. 1988. Common Lisp Object System specification. ACM SIGPLAN Notices 23.

....[7] and Java [36] has adopted a static object model, where the structure of an object is fixed by its type, and cannot be modified at run time. Models have been proposed in which the structure of an object can be modified dynamically, i.e. while the system is running. Approaches such as CLOS [11] and Smalltalk [32] that include some capability for reflection , are good examples of this. A restricted dynamic object model is also found in the Python language [87] where an object can gain new operations. Although there is some evidence that multimedia systems might benefit from the use of ....

D.G. Bobrow, L.G. Demichiel, R.P. Gabriel, S.E. Keene, G. Kiczales, D.A. Moon. Common Lisp Object System Specification. Lisp and Symbolic Computation, 1(3/4), 1989.

....for constructing and decomposing elements of abstract syntax. The elements will usually be grouped by static or dynamic system types. In PVS the elements of abstract syntax are modelled by CLOS objects grouped in classes 1 . In HOL the abstract syntax 1 CLOS is the Common LISP Object System [8] 4 is defined by an SML interface (defining an abstract data type) which is implemented by a structure containing a HOL data type. Semantics This element should, as far as possible, encapsulate any functionality that implies semantic constraints on the system, for example type checking the ....

Bobrow D, Michiel LG, Gabriel RP, Keene SE, Kiczales G, Moon DA, Common Lisp Object System Specification. SIGPLAN Notices, vol. 23., 1988.

....un nouvel objet, poss edant un slot apply, et de l associer comme ex ecutant du slot concern e. Dans l exemple qui suit, nous voulons etendre le comportement de base d un slot, afin d accomplir une action donn ee apr es son application standard, de mani ere analogue aux aftermethods de CLOS [BDGKKM88]. La r ealisation propos ee consiste a d efinir un objet poss edant une m ethode apply (lignes 7 a 10) et de lui faire m emoriser une action sous forme d un bloc actionBlock (ligne 5) a un argument (le receveur de l envoi de message) Le code ci dessous pr esente l impl ementation d un ....

D.G. Bobrow, L.G. DeMichiel, R.P. Gabriel, S. Keene, G. Kickzales and D.A. Moon. Common Lisp Object System Specification. Technical Report 87-002, ANSI Common Lisp Committee X3J13, 1987.

....other Lisps, functions themselves are first class values. EULISP breaks with LISP tradition in describing all its types (in fact, classes) in terms of an object system. This is called The EULISP Object System, or TEO Sigma. TEO Sigma incorporates elements of the Common Lisp Object System (CLOS) [Bobrow et al. 1988], ObjVLisp [Cointe, 1987] Oaklisp [Lang Pearlmutter, 1988] and MicroCeyx [Chailloux et al., 1987] The greatest debt of TEO Sigma is to CLOS, from which it takes the ideas of generic functions and multi methods. In addition, most of the terminology, the names and format of the user level ....

Bobrow D.G., DiMichiel L.G., Gabriel R.P., Keene S.E, Kiczales G. & Moon D.A, Common Lisp Object System Specification, SIGPLAN Notices, Vol. 23, September 1988.

No context found.

Bobrow, B.; DeMichiel, D.; Gabriel, R.; Keene, S.; Kiczales, G.; ; and Moon, D. 1988. Common lisp object system specification. Technical Report 88-002R, X3J13.

No context found.

D. G. Bobrow, L. G. DiMichiel, R. P. Gabriel, S. E. Keene, G. Kiczales, and D. A. Moon. Common Lisp Object System Specification. In SIGPLAN Notices 23, September 1988.

No context found.

D. G. Bobrow, L. G. DiMichiel, R. P. Gabriel, S. E. Keene, G. Kiczales, and D. A. Moon. Common Lisp Object System Specification. In SIGPLAN Notices 23, September 1988.

No context found.

D. G. Bobrow, L. G. DiMichiel, R. P. Gabriel, S. E. Keene, G. Kiczales, and D. A. Moon. Common Lisp Object System Specification. In SIGPLAN Notices 23, September 1988.

No context found.

D. G. Bobrow, L. G. DiMichiel, R. P. Gabriel, S. E. Keene, G. Kiczales, and D. A. Moon. Common Lisp Object System Specification. In SIGPLAN Notices 23, September 1988.

No context found.

Bobrow, B., DeMichiel, D., Gabriel, R., Keene, S., Kiczales G., Moon, D.: Common Lisp Object System Specification, June 1988, X3J13 Document 88-002R.

No context found.

BOBROW,D.G.,DEMICHIEL,L.G.,GABRIEL,R.P., KEENE, S. E., KICZALES,G.,AND MOON, D. A. 1988. Common LISP Object System specification. X3J13 Document 88-002R.

No context found.

D. Bobrow, L. DeMichiel, R. Gabriel, S. Keene, G. Kiczales, and D. Moon. Common lisp object system specification. In special issue, number 23 in SIGPLAN Notices, September 1988.

No context found.

Daniel Bobrow, Linda Demichiel, Richard Gabriel, Sonya Keene, Gregor Kiczales and David Moon, "Common Lisp Object System Specification", X3J13 Document 88-002R, June 1988.

No context found.

Daniel Bobrow, Linda Demichiel, Richard Gabriel, Sonya Keene, Gregor Kiczales and David Moon, "Common Lisp Object System Specification", X3J13 Document 88-002R, June 1988.

No context found.

Daniel Bobrow, Linda Demichiel, Richard Gabriel, Sonya Keene, Gregor Kiczales and David Moon, "Common Lisp Object System Specification", X3J13 Document 88-002R, June 1988.

No context found.

D. Bobrow, R. DeMichiel, S. Keene, G. Kiczales, and D. Moon. Common lisp object system specification. Sigplan Notices, 23(9), 1988.

No context found.

Daniel G. Bobrow et al. Common Lisp Object System Specification. Technical Report 87001, ANSI, September 1987.

No context found.

Daniel G. Bobrow, Linda G. DiMichiel, Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales, and David A. Moon. Common Lisp Object System specification. Lisp and Symbolic Computation, 1(3/4):245-- 394, January 1989. Republished in revised form as Chapter 28 of

No context found.

Bobrow, D.G., et al., Common Lisp Object System Specification. SIGPLAN Notices, 1988. 23.

No context found.

D.G. Bobrow, L. DeMichiel, R. Gabriel, S. Keene, G. Kiczales, and D. Moon. Common Lisp Object System Specification, X3J13 document 88-002r. In Common Lisp, The language, chapter 28, pages 770--864. Digital Press, second edition, 1990.

No context found.

D.G. Bobrow, L.G. DeMichiel, R.P. Babriel, S. Keene, G. Kiczales, and D.A. Moon. Common lisp object system specification. ACM SIGPLAN Notices, 23, September 1988.

No context found.

Daniel G. Bobrow, Linda G. DeMichiel, Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales, and David A. Moon. Common Lisp Object System Specification. In Sigplan Notices, volume 23 (Special Issue), September 1988.

No context found.

D.G. Bobrow, L.G. Demichel, & al., Common Lisp Object System Specification. X3J13 Document 88-002R, Juin 1988

No context found.

D.G. Bobrow, L.G. DeMichiel, R.P. Gabriel, S. Keene, G. Kiczales, and D.A. Moon. Common lisp object system specification, x3j13. Technical Report 88-003, (ANSI COMMON LISP), 1988.

No context found.

D. Bobrow, L. DeMichiel, P. Gabriel, S. Kenne, G. Kiczales, and D. Moon. Common Lisp object system specification. ACM SIGPLAN Notices, 23, 1988.

No context found.

Daniel G. Bobrow, Linda G. DeMichiel, Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales, and David A. Moon. Common Lisp object system specification. SIGPLAN Notices, 23, September 1988. X3J13 Document 88-002R, June 1988. Ref. on pages 4, 45.

No context found.

Bobrow, D. G., L. G. DeMichiel, R. P. Gabriel, S. E. Keene, G. Kiczales and D. A. Moon, "Common Lisp Object System Specification," Document, 88-002R, 1988.

No context found.

D.G. Bobrow, L.G. DeMichiel, R.P. Gabriel, S.E. Keene, G. Kiczales, and D.A. Moon. Common Lisp Object System Specification. SIGPLAN Notices, 23, September 1988. 20

No context found.

Daniel G. Bobrow, Linda G. DeMichiel, Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales, and David A. Moon. Common Lisp object system specification. X3J1J Document 88002R, June 1988.

No context found.

Daniel G. Bobrow, Linda G. DeMichiel, Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales, and David A. Moon. Common Lisp Object System specification, June 1988. X3J13 Document 88-002R.

No context found.

Daniel G. Bobrow, Linda G. DeMichiel, Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales, and David A. Moon. Common lisp object system specification. SIGPLAN Notices, September 1988.

No context found.

D. G. Bobrow, L. G. DeMichiel, R. P. Gabriel, S. Keene, G. Kiczales, and D. A. Moon. Common Lisp Object System specification. SIGPLAN Notices, 23(9), 1988.

No context found.

Daniel G. Bobrow, Linda G. DeMichiel, Richard P. Gabriel, Sonya Keene, Gregor Kiczales, and David A. Moon. Common Lisp Object System specification. SIGPLAN Notices, 23, Sept. 1988.

No context found.

Daniel G. Bobrow, Linda G. DeMichiel, Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales, and David A. Moon. Common Lisp object system specification. SIGPLAN Notices, 23, September 1988. special issue.

First 50 documents  Next 50

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