| S. E. Keene. Object-Oriented Programming in Common Lisp. Addison Wesley, 1989. |
....to the natural evolution of a system from more disorganized states to more optimized ones, the object representation should also follow a natural evolutionary path. A lot of OODLs (object oriented dynamic languages) have been developed, for instance Smalltalk [GoRo83] SELF [UnSm87] CLOS [Keen89], and Dylan [Appl92] All these languages claim to support especially the development of adaptive software systems. Chameleon is an experimental OODL. Its outstanding aim is to support the evolutionary development of open yet secure object oriented systems by means of a simple object model as well ....
S.E.Keene; Object-Oriented Programming in Common Lisp; Addison-Wesley; 1989.
....focus of the more specific, detailed remainder of this paper. 2 Some CLOS Facts This paper cannot provide an in depth tutorial of CLOS. Reference [3] is the official reference for the CLOS programmer. It explains the concepts and contains manual pages for all the built in operations. Reference [4] is an excellent introduction with a good balance between formal and informal presentation. It also contains many useful examples. CLOS consists of the standard Common Lisp [5] with an object model added to it. We now outline the central concepts in just enough detail to prepare for a subsequent ....
Sonya E. Keene. Object-Oriented Programming in Common Lisp. Addison-Wesley Publishing Company, 1989.
....programmers have long realized that single inheritance is not expressive enough to factor out common features (i.e. instance variables and methods) shared by classes in a complex hierarchy. As a consequence, language designers have proposed various forms of multiple inheritance [7, 23, 29, 35, 41], as well as other mechanisms such as mixins [3, 10, 18, 27, 32] that allow classes to be composed incrementally from sets of features. Despite the passage of nearly twenty years, neither multiple inheritance nor mixins have achieved wide acceptance [44] Summarizing Alan Snyder s contribution to ....
Sonia E. Keene. Object-Oriented Programming in Common-Lisp. Addison Wesley, 1989.
....scores are indicated and we see that there are still violated constraints. The next step would be performed as exemplified in figure c) 5. 5 Implementation The AAAO model is implemented in Common Lisp [ Steele, 1984 ] Steele:84) and its object oriented extension CLOS (Common Lisp Object System, Keene, 1989 ] Keene:89) The AAAO model is implemented in full detail for the adaptation of column positions on a floor to fit a certain use. The object oriented implementation, however, was designed to be extendable to other tasks in building design as well. All essential parts of the model are ....
S. Keene. Object-OrientedProgramming in Common Lisp. Addison-Wesley, 1989.
....programmers have long realized that single inheritance is not expressive enough to factor out common features (i.e. instance variables and methods) shared by classes in a complex hierarchy. As a consequence, language designers have proposed various forms of multiple inheritance [Mey88] Kee89] Str86] as well as other mechanisms, such as mixins [Moo86] BC90] FKF98] that allow classes to be composed incrementally from sets of features. Despite the passage of nearly twenty years, neither multiple inheritance nor mixins have achieved wide acceptance [Tai96] Summarizing Alan Snyder s ....
Sonia E. Keene. Object-Oriented Programming in Common-Lisp. Addison Wesley, 1989.
....in the matrix structure. After the specification of our structures is given (by following the formalism defined in [4] we present theironeimplementation in suitable classes. In this implementation the derivation of a structure from another is expressed by specialization inheritance. Clos [2] is the programming language used. It has been chosen for a number ofreasons: because of its object orientation# because it has been already used within a project, in whichwehave been involved, aiming to the development of a language for symbolic computation systems [3] and for our involvement in ....
Sonya E. Keene. Object OrientedProgramming in Common Lisp. Addison Wesley Publishing Company, 1989.
....name. However, the e#ect of having multiple instance variables with the same 3 name is that the most specific one overrides the others; even though this can be used to simulate such features as class variables, it is also somewhat confusing and error prone. Finally, a defmethod form in a CLOS [6] program introduces a method implementation having a certain name and a certain argument list. This method will become one of the methods contained in some generic function of the same name having a congruent argument list (i.e. primarily, having the same number of required arguments) and ....
Sonya E. Keene. Object-Oriented Programming in Common Lisp. Addison-Wesley, Reading, MA, USA, 1989.
....valueWithReceiver:arguments: defined on the class MethodWrapper. 5.2 Message Passing Control in Other Languages. CLOS is the object system integrated into Common Lisp. It is one of the few class based languages to offer the ability to define instance specific methods using the eql specializer[Kee89] Moreover CLOS is also one of the rare languages to provide a meta object protocol (MOP) in which message passing control is an entry point [KdRB91] In CLOS the message passing concept is replaced by the generic function 4 The CLOS MOP allows one to control all the aspects of the generic ....
S. E. Keene. Object-Oriented Programming in Common-Lisp. Addison-Wesley, 1989.
....C 3. When mixins [3, 2, 4, 9, 8] are supported, a mixin may be considered an aspect of the class to which it is applied 4. With multiple inheritance, a class C j may be considered as an aspect of a class C i in the construction of a new class C : C 1 : C k (as with CLOS style mixin classes [10]) 5. An AspectJ aspect may be considered as an aspect of the class it a ects (it may, e.g. add elds, methods, and statements within methods to its target class) 6. A module system (such as the one in gbeta) can support the addition of local classes, elds, and methods to classes, cases to ....
Sonya E. Keene. Object-Oriented Programming in Common Lisp. Addison-Wesley, Reading, MA, USA, 1989.
....with the same name, inherited from two or more superclasses. Which one of those attributes should be used for a given application of the common name One way to automatically resolve ambiguities is to linearize the inheritance graph. This approach was taken in several languages including CLOS [18] and Dylan [33] An extra bene t of linearization is that not only name lookup but also method combination has a natural de nition when the list of superclasses has been established. In CLOS, e.g. method combination is supported using before methods, after methods, and call next method. The ....
....All these systems are very exible. The exibility goes along with a very rich universe of potential program executions, and this makes it dicult to prove that any speci c properties hold about individual program elements in other words, they are not designed for static type checking. The CLOS [18] convention of using some classes for mixin inheritance has been developed [5, 11, 34] into a separate concept of mixin based inheritance. A mixin is a class modifying device, supporting inheritance directly as an incremental modi cation that may be applied to several di erent classes. In [34, ....
Keene, Sonya E. 1989. Object-Oriented Programming in Common Lisp. Addison -Wesley, Reading, MA, USA.
....particular language, but that is only because so few object oriented languages offer general block structure and virtual classes. With the introduction of inner classes in Java and the possible addition of virtual types [24] or a similar mechanism, the same techniques would apply here. Since CLOS [12] programmers introduced mixin classes as a particular programming style in context of linearization based multiple inheritance, a related but separate concept of mixins and mixin based inheritance has emerged [2, 3, 23, 8] Inheritance allows for the creation of one new class, based on zero or ....
....as mentioned in Sect. 4, the fundamental mechanisms of gbeta the new semantics of virtuals and the support for class combination are so different that a complete reimplementation was required. To our knowledge there are no existing systems which support a mechanism like our propagation. CLOS [12] was an important source of inspiration, and gbeta does not have an equivalent of the CLOS meta object protocol; it is probably necessary for static type checking to lay down a firm foundation for the language and not let everything be user definable. Thus, in addition to the propagation ....
Sonya E. Keene. Object-Oriented Programming in Common Lisp. Addison-Wesley, Reading, MA, USA, 1989.
....need considerable modification. 12 We should also mention the work of Lamping and Abadi [8] in which they formalize polymorphism in a very general manner allowing method selection to depend on a variety of criteria such as on the types of all the operands (multi methods as in Cecil [3] or CLOS [7]) or even real time considerations (as in DROL [15] But their focus is on formalizing how the method is chosen (by the run time system) rather than on reasoning about behaviors. Nevertheless it would be interesting to see if some of their ideas can be used as a generalization of our ObIds, ....
S. E. Keene. Object-Oriented Programming in Common Lisp. Addison-Wesley, 1989.
....Dynamic object oriented languages are languages that allow dynamic runtime creation of class de nitions (as well as other run time modi cations of 2 the class hierarchy) Thus the complete class hierarchies are not known at compile time or at any stage preceding the actual program execution. CLOS [20] and Smalltalk are two such languages. Additionally, prototype based languages [3, 5, 33] are also examples of such languages. Name resolution in presence of late binding is easily solved for static object oriented languages (such as Java and C ) since the complete class hierarchy is known at ....
S.E. Keene. Object-oriented Programming in Common Lisp. Addison Wesley, 1988.
....development of class hierarchies e.g. a subclass can be implemented before its superclass has been implemented. Mixin inheritance can be used to model single inheritance and many common forms of multiple inheritance [11, 9] Mixins were first introduced in the Flavors system [38] and CLOS [33], although as a programming idiom rather than a formal language construct. Our calculus is an attempt to formalize mixins as the basic mechanism underlying all inheritance. To ensure that mixin inheritance can be statically type checked, our calculus employs constrained parameterization. From each ....
S. Keene. Object-Oriented Programming in Common Lisp. Addison-Wesley, 1989.
....Java virtual machine: dynamic class loading. This is the underlying mechanism that provides much of the power of the Java platform: the ability to install software components at runtime. An example of a component is an applet that is downloaded into a web browser. While many other systems [16] [13] also support some form of dynamic loading and linking, the Java platform is the only system we know of that incorporates all of the following features: 1. Lazy loading. Classes are loaded on demand. Class loading is delayed as long as possible, reducing memory usage and improving system response ....
....by the Java virtual machine. In contrast, existing dynamic linking mechanisms do not support all of these features. Although most operating systems support some form of dynamic linked libraries, such mechanisms are targeted toward C C code, and are not type safe. Dynamic languages such as Lisp [13], Smalltalk [6] and Self [21] achieve type safety through additional run time checks, not link time checks. The main contribution of this paper is to provide the first in depth description of class loaders, a novel concept introduced by the Java platform. Class loaders existed in the first ....
Sonya E. Keene. Object-Oriented Programming in Common Lisp. Addison-Wesley, 1989.
....the matrix structure. After the specification of our structures is given (by following the formalism defined in [4] we present their one to one implementation in suitable classes. In this implementation the derivation of a structure from another is expressed by specialization inheritance. Clos [2] is the programming language used. It has been chosen for a number of reasons: because of its object orientation; because it has been already used within a project, in which we have been involved, aiming to the development of a language for symbolic computation systems [3] and for our involvement ....
Sonya E. Keene. Object Oriented Programming in Common Lisp. Addison Wesley Publishing Company, 1989.
....The external presentation was realized by a pretty printer based on a straightforward tree traversal during which the current focus was indicated clearly. The persistent representation of a model consist of nested activations of Lisp constructor functions (along the style recommended by Keene [ 8 ] page 163) Roughly, there exists a constructor function for each constructor found in the abstract grammar. Using these simple means we were able to construct our first dynamic models, and to get some important preliminary experience with our ideas. The investment was only a few days of ....
Sonya E. Keene. Object-Oriented Programming in Common Lisp. Addison-Wesley Publishing Company, 1989.
....modifcation. 13 It may also be appropriate to mention here the work of Lamping and Abadi [8] in which they formalize polymorphism in a very general manner allowing method selection to depend on a variety of criteria such as on the types of all the operands (multi methods as in Cecil [3] or CLOS [7]) or even real time considerations (as in DROL [15] But their focus is on formalizing how the method is chosen (by the run time system) rather than on reasoning about behaviors. Nevertheless it would be interesting to see if some of their ideas can be used as a generalization of our ObIds, ....
S. E. Keene. Object-Oriented Programming in Common Lisp. Addison-Wesley, 1989.
....allowing object to be computed and updated using other objects as arguments to appropriate methods. Multiple inferences may be defined for an attribute, and may be triggered independently depending on the arguments availability. This will be the basis for a powerful method combination mechanism [13]. 2.3 Semantic relationships A critical issue in design application is the support for user defined relationships between objects. Whereas many object oriented systems now provide some form of composite objects [14, 15] an open question is the implementation of versatile semantic relationships. ....
....framework, it is used as a foundation for extensibility of the model. As an implementation tool, it forms the bootstrap of the model SHOOD itself. It serves the purpose of generating the whole model from a reduced set of meta classes. This approach bears similarities with ObjVlisp and CLOS [6, 13]. 3.1 Meta classes All the classes defined in SHOOD are instances of meta classes. The latter defines the structure and behavior of the classes. For example the class Aircraft is an instance of the meta class Meta as depicted in figure 1. The meta class Meta defines the minimal attributes and ....
Keene S.E. Object-oriented programming in Common Lisp. A programmer's guide to CLOS. Addison-Wesley. 1989.
....of engines in an ongoing project for goal driven explanation, gobie 3 . Further details about gobie and the motivations behind the project may be found in [17, 12] gobie is a system for performing explanation in a dynamic goal driven manner. It is an object oriented system written in CLOS [1, 9]. The system consists of a planner functioning in a simple simulated world and a case based explainer [15] integrated across a blackboard. Case based explanation applies the problem solving paradigm of case based reasoning [11] to the problem of formulating explanations: new explanations are ....
Sonya E. Keene. Object-Oriented Programming in Common Lisp. Addison-Wesley Publishing Company, 1989.
....systems are very flexible. The flexibility goes along with a very rich universe of potential program executions, and this makes it difficult to prove that any specific properties hold about individual program elements in other words, they are not designed for static type checking. The CLOS [14] convention of using some classes for mixin inheritance has been developed [4, 10, 22] into a separate concept of mixin based inheritance. A mixin is a class modifying device, supporting inheritance directly as an incremental modification that may be applied to several different classes. In ....
Sonya E. Keene. Object-Oriented Programming in Common Lisp. Addison-Wesley, Reading, MA, USA, 1989.
....different representations (e. g ART, KEE, Knowledge Craft, see [43] for a comparison) Such programming techniques were often developed and widely used before a proper formal understanding of them was available (witness e.g. the certainty factor model in MYCIN [15] or multiple inheritance in LOOPS [48]) Although shells like EMYCIN [78] and others made some progress towards abstraction, they were still presented in terms of the representation language and inference engine they provided. The move away from this first period was already heralded as early as 1980 by Alan Newell in his knowledge ....
S. E. Keene. Object-Oriented Programming in Common Lisp. Addison-Wesley, 1989.
....this material is kept at an abstract level and does not require deep knowledge of CLOS particulars. Sections 3.4 and 3.5 are much more concrete. They present selected details of the MOP using an example that is introduced in section 3.3. These sections do assume knowledge of CLOS as explained in [4, 5]. The main body of the chapter closes with pointers to related work and the conclusion. Appendices provide some material about the MOP which is useful for the deeply interested reader but which are too detailed to include in the text. 3.2 The Metaobject Protocol Beyond trying to be a powerful ....
Sonya E. Keene. Object-Oriented Programming in Common Lisp. Addison-Wesley Publishing Company, 1989.
....A should be; in fact, the schema is not well defined. To resolve this problem, we could employ one of the two strategies ordinarily used in IS A hierarchies: Either we could disallow such ambiguous value propagation altogether and consider the schema invalid, or we could employ a precedence list [14, 28]. However, in part hierarchies, there exists a third strategy which is a more natural solution. Often, it is sensible to model a property of the whole in terms of the values of the same property at its parts, regardless of their classes. Many examples readily come to mind: the color of an airplane ....
S. E. Keene. Object-Oriented Programming in Common Lisp. Addison-Wesley Publishing Co., Inc., Reading, MA, 1989.
....interface which, among other things, supports generic primitives for asserting and retracting knowledge, and for posing queries to the system. The role of these generic primitives is similar to the one played by the functional interface to Cyc (Lenat Guha, 1990) or by generic functions in CLOS (Keene, 1989): they specify the functionalities of a system in a way which is independent from its actual implementation. In the case of the VITAL KR, the generic primitives define an abstract interface not only between the hybrid system and the external world (i.e. the user, or other tools) but also between ....
Keene, S. (1989). Object-Oriented Programming in Common Lisp. Addison-Wesley, Reading, Massachussets.
....interface which, among other things, supports generic primitives for asserting and retracting knowledge, and for posing queries to the system. The role of these generic primitives is similar to the one played by the functional interface to Cyc (Lenat Guha, 1990) or by generic functions in CLOS (Keene, 1989): they specify the functionalities of a system in a way which is independent from its actual implementation. In the case of the VITAL KR, the generic primitives define an abstract interface not only between the hybrid system and the external world (i.e. the user, or other tools) but also between ....
Keene, S. (1989). Object-Oriented Programming in Common Lisp. Addison-Wesley, Reading, Massachussets.
....object has a different visualization and interaction behavior. This section describes the constructs supplied to assemble PO s into programs. First, we must take a more detailed look at the structure of a PO. Each instance of a PO is repreFigure 2. A CIM Database Browser 9 sented by a CLOS [7] object with slots that hold code, variables and parameters, lexical structuring information, and graphical interface components. We treat each of these in order. PO s have four code segments: load code, setup code, init code, and exit code. Load code is executed when the PO is first loaded into ....
Keene, S. Object-Oriented Programming in Common Lisp, Addison-Wesley, 1988. -26-
....the example above the execution of the sequence S 2 means just that of the modules M 23 ; Delta Delta Delta ; M 2n . 4 Implementation We have implemented a prototype of the vision planner described in the last section on Sun workstations with Common Lisp and Common Lisp Object System (CLOS) [13, 15]. The current version runs in the interative Lisp environment. The communication with the robot system is simulated by a dialog with the user. The syntax of the vision commands are (find one object database object) find all objects (database database . find top object (database database ....
S. E. Keene, Object-oriented programming in Common Lisp, Addison Wesley, 1989.
....at instantiation time of a task network. Changing the static type properties means changing the constraints that regulated the shape of an existing network. The rule i convert attempts to convert an active task to a modified type definition, see CLOS update instance for redefined class [Kee89] A task must be treated with regard to its state. The core of rule i convert does not depend on whether the type change has been done by subtyping or by versioning. In fact we believe that the most frequent changes involve redefinition of the predefined type level properties. Then rule i convert ....
Sonya E. Keene. Object-Oriented Programming in Common Lisp. Addison Wesley, 1989. 266 p.
....to apply not only to dynamic languages but to several other systems. In particular, static typing is not explored in Rascal. Also, compositional nesting, as given in the following chapter, is unique to CMS. A popular language family for OO programming with Lisp is the CLOS family of languages [45, 50]. CLOS supports a quite different model of OO programming from the one described here, with multiple dispatch, generic functions, but much weaker encapsulation. CMS, on the other hand, supports only single dispatch. CLOS also supports a protocol to interact with its meta architecture. Dexterity of ....
....more involved than what is described here, due to the desirability of symmetric class and metaclass hierarchies, but the given description will suffice for this discussion. 5.5. 2 CLOS The CLOS object system supports the standard concept of classes, which can be instantiated into instances [45]. Class attributes are called slots. A distinguishing feature of the CLOS model is the notion of generic functions which are defined independent of any class and can be specialized into methods that are applicable to specific classes. Generic functions can be dispatched based on multiple arguments ....
Keene, S. E. Object-Oriented Programming in Common Lisp. AddisonWesley, Reading, MA, 1989.
....for more powerful language constructs. While our analysis primarely focuses on the machanisms as found in Smalltalk, we compare possible extensions to similar mechanisms found in other languages. 4. 1 Blocks The block construct from Smalltalk (and its sibling the lambda expression from Scheme [Keene, 1989]) is a powerful abstraction mechanism with roots in function theory. We will in this section examine this abstraction mechanism from a conceptual perspective. The purpose is to illustrate the perspective of conceptual understanding on programming languages. Traditionally the block construct is ....
....if it takes exceptional effort or skill to write such programs; in that case, the language merely enables programmers to use the technique. We give examples of the use of the framework on the object oriented languages Smalltalk, Beta, C [Ellis and Stroustrup, 1990] Eiffel [Meyer, 1992] CLOS [Keene, 1989] , and Self [Ungar and Smith, 1987] Object oriented languages may also be discussed and analyzed without involving conceptual modeling cf. Bobrow and Stefik, 1985] and [Wegner, 1987] We examine object oriented languages because these fit excellent, not only with classification and ....
S. E. Keene. Object--Oriented Programming in Common Lisp. Addison Wesley, 1989.
....also dioeerent: we rely on an implicit approach where free references are implicitly abstracted when appearing into the scope of a de nition whereas for the C calculus, contexts need to be explicitly abstracted and solved. Mixins and modularity. After its rst introduction in the LISP community [21, 34] to represent an abstract subclass, the notion of mixin has been widespread in the object oriented community to denote a class where some components of dioeerent nature (types, exceptions, methods, slots, are not de ned. The de nition of such component is deferred and can eoeectively be used ....
Keene, S. E. Object-Oriented Programming in Common Lisp. Addison Wesley, Reading, Mass., 1989.
....scope, although one type of scope may be more efficient than the other in some situations. Dynamic scope allows for a special style of programming well suited for systems where name lookup needs to be done dynamically. The object oriented language CLOS is defined using dynamically scoped Lisp [30]. Most features of the Gnu Emacs editor are programmed in the dynamically scoped lisp dialect Elisp. The program transformations described in the later chapters are designed for lexically scoped languages. To avoid confusion, we assume that we only work with such languages. Procedures are ....
Sonya E. Keene. Object-Oriented Programming in Common Lisp. Addison-Wesley, 1989.
No context found.
S. E. Keene. Object-Oriented Programming in Common Lisp. Addison Wesley, 1989.
No context found.
Sonya E. Keene. Object-Oriented Programming in COMMON LISP. A Programmers Guide to CLOS. Addison-Wesley, 1989.
No context found.
Keene, S. E. Object-Oriented Programming in Common Lisp. Addison Wesley, Reading, Mass., 1989.
No context found.
Keene, S. E. Object-OrientedProgramming in Common Lisp. Addison-Wesley, 1989.
No context found.
Keene, S. E., (1989), Object-OrientedProgramming in Common Lisp. Reading, MA: AddisonWesley.
No context found.
Sonya E. Keene. Object-Oriented Programming in Common Lisp. Addison-Wesley, Reading, MA, 1989.
No context found.
Keene, S. E., (1989), Object-Oriented Programming in Common Lisp. Reading, MA: AddisonWesley.
No context found.
Sonya E. Keene, Object-Oriented Programming in Common LISP, Addison-Wesley (1989).
No context found.
Sonya E. Keene, Object-Oriented Programming in Common Lisp, Addison-Wesley, 1989.
No context found.
S. E. Keene, Object-Oriented Programming in Common Lisp, Addison-Wesley, 1989.
No context found.
S.E. Keene, Object-Oriented Programming in Common Lisp, A Programmer's Guide to CLOS, Addison-Wesley, Reading, MA, 1988.
No context found.
Sonya E. Keene. Object-Oriented Programming in Common Lisp, Addison-Wesley Publishing Company, 1988.
No context found.
Sonya E. Keene. Object-Oriented Programming in Common Lisp. Addison-Wesley, Reading, Mass., 1989. 43
No context found.
Sonya E. Keene. Object-Oriented Programming in COMMON LISP. AddisonWesley, 1989.
No context found.
Keene, S. E., Object-Oriented Programming in Common Lisp, AddisonWesley, 1989.
No context found.
Keene, S., (1989) Object-Oriented Programming in Common Lisp, A Programmer's Guide to CLOS. Addison Wesley, Reading, Massachusetts.
No context found.
Keene, S (1989). Object-Oriented Programming in Common Lisp, Reading, MA: Addison-Wesley Publishing.
First 50 documents Next 50
Online articles have much greater impact More about CiteSeer.IST at NUS Add search form to your site Submit documents Feedback
CiteSeer.IST at NUS - Copyright Penn State and NEC. Hosted by the School of Computing, National University of Singapore.