DOCSLIB.ORG

Using a Loadtime Metaobject Protocol to Enforce Access Control Policies Upon User-Level Compiled Code

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Using a Loadtime Metaobject Protocol to Enforce Access Control Policies Upon User-Level Compiled Code USING A LOADTIME METAOBJECT PROTOCOL TO ENFORCE ACCESS CONTROL POLICIES UPON USER-LEVEL COMPILED CODE ,\ DISSERTAIION SUBMITTED TO THE SCHOOL OF C();-"ll'lTI~G OF THE UNIVERSITY OF NEWCASTLE-UPON-TYNE IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY Ian S. Welch September 2004 NEWC~STL[ UNIVCRSITY LICRARY 204 OGJ32 0 © Copyright by Ian S. Welch 200-+ All Rights Reserved 11 Dedication To my partner Jim and, my family especially my parents Stan and Claire. III Acknowledgements I would like to express my sincere gratitude to "everal people \\ho ha\e contributed in various ways to the completion of this thesis. The advice and patience of my supervisor, Dr. Robert Stroud, \\ <1" crucial in the comple­ tion of this work. Also, many thank.., to the Defence and Research Agency and particularly Dr. Peter Y. Ryan for providing the financial support, advice and encouragement needed to fini..,h my work. While at Newcastle, the advice and help given to me by a large number of people, in particular Dr. G. Morgan, Mr J. Warne, Dr. A.S. McGough, Dr. B. ArieL Dr. A. Ro­ manovsky, and Dr. C. Gaciek kept me going. Since leaving Newca..,tle and coming to \\ork at Victoria University, I have been greatly helped by the contributions of my colleagues. Participation in the Circle of Guilt has been a great help in completing but abo staying sane. Special thanks also to Margi Key" for helping proofread the final thesi" and keeping me on the straight and narrow with the use of my hyphens! Finally, I would not have started or completed this thesis if it hadn't been for the en­ couragement and support of my partner, Jim Whitman. \\ Contents Dedication iii Acknowledgements i, 1 Introduction 3 1.1 The Thesis. -l 1.2 Motivation. 1.2.1 New Problem Domains . 5 1.2.2 Man-machine Scale. 8 1.2.3 Criteria for Evaluation 9 1.2.-+ Operating System Enforcement 10 1.2.5 Conventional Object-Oriented Techniques . 10 1.2.6 In-lined Reference Monitors 12 1.2.7 Metaobject Protocols 13 1.2.8 Loadtime Metaobject Protocols 14 1.3 Contributions 15 1.3.1 Design and Implementation of a Secure Loadtime Metaobject Pro- tocol ................................ IS 1.3.2 Demonstration of the Limitations of Conventional Object-Oriented Techniques . 18 1.3.3 Evaluation of Separation of Concerns 18 1.-+ Thesis 0\ enil'\\ 18 \ 2 Related Work 20 2.1 Access Control Policies. 21 2.2 Criteria for Evaluation 2-l 2.2.1 Separation of Concerns . 2-l 2.2.2 Security Engineering Principles 26 2.3 Operating System Enforcement . 27 2.3.1 Evaluation 27 2.4 Conventional Object-oriented Security 29 2.4.1 Examples 30 2.4.2 Evaluation 35 2.5 In-lined Reference Monitors 38 2.5.1 Evaluation 39 2.6 Metaobject Protocols -l-l 2.6.1 Examples -l8 2.6.2 Evaluation 51 2.7 Goals of Thesis 5-l 3 Design and Implementation of Kava 57 3.1 Language Design of Kava. 58 3.1.1 Overview 59 3.1.2 Kava Metaobject Protocol 60 3.1.3 Context Parameters . 64 3.IA Binding 66 3.1.5 Meta Parameters 67 3.1.6 Meta-Level Cooperation 69 3.1.7 A Misbehaved Applet 70 3.2 Kava Implementation 71 3.2.1 Overview 72 3.2.2 Intercepting Class Loading . N 3.2.3 Adding Meta-Level Interceptions 75 3.2A Realising MUs 7R \'\ 3.2.5 Static Analysis ..... 79 3.2.6 Instantiating Metaobjects . 80 3.2.7 Reification .. 80 3.2.8 Static Members XI 3.2.9 Implementing Complete Mediation 3.2.10 Performance ........... 89 3.2.11 Example: Redefining Field Access. 90 3.3 Evaluation against Goals . 92 3.3.1 Enforcement upon Compiled Code. LJ2 3.3.2 Control Access to Application, Library and Operating S} -,tern Re- sources ........... 3.3.3 Clean Separation of Concerns 3.3.4 Least Privilege ... 93 3.3.5 Complete Mediation l)~ 3.3.6 Economy of Mechanism l)~ 3.4 Summary . LJ5 4 Case Study One: Standalone Application 96 -+.1 Overview . 96 ~.2 Conventional Object-oriented Security 97 -+.2.1 Application Resources 97 ~.2.2 System Resources 100 ~.3 Loadtime MOP . 104 ~.3.1 Application Resources I()~ -+.3.2 System Resources .. 106 ~.~ Improvements to the Separation of Concerns. 110 ~.5 Summary . 112 5 Case Study Two: Distributed Application 113 5.1 Overview .............. 113 5.2 Conventional Object-oriented Security 115 5.2.1 O\enie\\ ....... 115 \11 5.2.2 Secure RMI .. 116 5.2.3 Security State . 116 5.2.4 Authorisation 118 5.3 Loadtime MOP 121 5.3.1 Overview 121 5.3.2 Secure RMI . 123 5.3.3 Security State . 12-l 5.3.4 Authorisation . 125 5.4 Improvements to the Separation of Concerns. 126 5.4.1 Place Enforcement within Libraries 126 5.4.2 Place Enforcement within Proxies . 127 5.4.3 Place Enforcement within a Superclass 129 5.5 Summary ....... 129 6 Inferences from Case Studies 131 6.1 MOPs Provide Better Separation of Concerns than Conventional Object- Oriented Techniques .................... 131 6.2 Constraints to Consider when Using MOPs for Enforcement 132 6.2.1 Detailed Specifications may be Necessary . 132 6.2.2 Expressiveness of Binding Influences Complexity of Use . 132 6.2.3 Granularity ofInterfaces Constrain Policies . 133 6.2.4 Security Exceptions Break Transparency ...... 134 6.2.5 Constraints upon Applying Kava to other Languages 134 6.3 Summary ........ 135 7 Conclusions and Future Work 136 7.1 Summary of Thesis . 136 7.2 Overall Contributions 140 7.3 Future Work ..... 143 7.3.1 Improve Static Analysis 1-l-l 7.3.2 Provide Least Privilege for Metaobjects l-l-l 7.3.3 Improve Metaobject Composition I .. t~ V III 7.3.4 Make Distribution First-Class . 1~5 7.3.5 Improve Economy of Mechanism 146 7.3.6 Investigate and Improve Performance 1~6 7.3.7 Provide a Policy Language for Kava 1~7 7.4 Concluding Remarks 148 Bibliography 149 IX List of Tables 2.1 Evaluation of operating system enforcement 2X 2.2 Evaluation of conventional object-oriented techniques. 36 2.3 Evaluation of IRM techniques -Hl 2.4 Classification of MOPs -+h 2.5 Evaluation of MOP techniques )2 2.6 Evaluation of security engineering techniques )) 7.1 Summary of evaluation of security engineering techniques 138 7.2 Applying Kava to Problem Domains 1-+2 x List of Figures 1.1 Layers of an IT system 9 1.2 Overview of Kava. 17 2.1 XACML authorisation. 23 2.2 Java security architecture 30 2.3 In-lined reference monitor architecture. 39 2.4 Metaobject and object . -+) 3.1 Context hierarchy ... 65 3.2 High-level object collaboration diagram showing objects and their interac- tions when a class is loaded into the Java VM .... 72 5.1 Class diagram for self-defence security architecture 117 5.2 Collaboration diagram showing steps involved in a viewer invoking a method of a remote database ............................. 120 5.3 Collaboration diagram showing the steps involved in invoke a method of a remote database under the reflective security architecture 122 7.1 Application model 140 XI Listings 3.1 Kava metaobject protocol 59 3.2 IFieldContext interface. 66 3.3 Example of overriding base-level behaviour 66 3.4 DTD for Kava binding specification 6~ 3.5 Kavakava replacement for Java. 7J 3.6 Kava's class loader. 76 3.7 Superclass containing MLI for method execution. 87 J.8 Subclass defining its own MetaObject to use for method executions. 87 3.9 A rewritten field access. 91 4.1 Defining a channel permission ()8 4.2 Grant access to join a specific channel <)<) 4.3 Explicit check for permission to create a channel 100 4.-1- Check for implication of permissions in class Write Permission. 102 4.5 Java policy limiting Lirc's access to the network 102 4.6 Check for permission to write to the network. 103 4.7 ChannelEnforcementMetaObject controlling access to IRC channels 105 4.8 Policy file for enforcing channel access control using Kava . 107 4.9 Meta-level enforcement code tracking the creation of OutputStream in- stances by sockets. .............................. 108 4.10 Meta-\eyel enforcement code checking whether Lirc has exceeded it'-> net- work quota..................... 109 4.11 Policy file for enforcing network quota using Kava I I 1 XII Abstract This thesis evaluates the use of a loadtime metaobject protocol as a practical mechanism for enforcing access control policies upon applications distributed as user-level compiled code. Enforcing access control policies upon user-level compiled code is necessary because there are many situations where users are vulnerable to security breaches because they download and run potentially untrustworthy applications provided in the form of user-level compiled code. These applications might be distributed applications so access control for both local and distributed resources is required. Examples of potentially untrustworthy ap­ plications are Browser plug-ins, software patches, new applications, or Internet computing applications such as SETI@home. Even applications from trusted sources might be mali­ cious or simply contain bugs that can be exploited by attackers so access control policies must be imposed to prevent the misuse of resources. Additionally, system administrators might wish to enforce access control policies upon these applications to ensure that users use them in accordance with local security requirements. Unfortunately, applications devel­ oped externally may not include the necessary enforcement code to allow the specification of organisation-specific access control policies.
Load more

Recommended publications
  • Metaobject Protocols: Why We Want Them and What Else They Can Do
    Metaobject protocols: Why we want them and what else they can do Gregor Kiczales, J.Michael Ashley, Luis Rodriguez, Amin Vahdat, and Daniel G. Bobrow Published in A. Paepcke, editor, Object-Oriented Programming: The CLOS Perspective, pages 101 ¾ 118. The MIT Press, Cambridge, MA, 1993. © Massachusetts Institute of Technology All rights reserved. No part of this book may be reproduced in any form by any electronic or mechanical means (including photocopying, recording, or information storage and retrieval) without permission in writing from the publisher. Metaob ject Proto cols WhyWeWant Them and What Else They Can Do App ears in Object OrientedProgramming: The CLOS Perspective c Copyright 1993 MIT Press Gregor Kiczales, J. Michael Ashley, Luis Ro driguez, Amin Vahdat and Daniel G. Bobrow Original ly conceivedasaneat idea that could help solve problems in the design and implementation of CLOS, the metaobject protocol framework now appears to have applicability to a wide range of problems that come up in high-level languages. This chapter sketches this wider potential, by drawing an analogy to ordinary language design, by presenting some early design principles, and by presenting an overview of three new metaobject protcols we have designed that, respectively, control the semantics of Scheme, the compilation of Scheme, and the static paral lelization of Scheme programs. Intro duction The CLOS Metaob ject Proto col MOP was motivated by the tension b etween, what at the time, seemed liketwo con icting desires. The rst was to have a relatively small but p owerful language for doing ob ject-oriented programming in Lisp. The second was to satisfy what seemed to b e a large numb er of user demands, including: compatibility with previous languages, p erformance compara- ble to or b etter than previous implementations and extensibility to allow further exp erimentation with ob ject-oriented concepts see Chapter 2 for examples of directions in which ob ject-oriented techniques might b e pushed.
    [Show full text]
  • Common Lisp Object System Specification 3. Metaobject Protocol
    Common Lisp Object System Specification 3. Metaobject Protocol This document was written by Daniel G. Bobrow, Linda G. DeMichiel, Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales, and David A. Moon. Contributors to this document include Patrick Dussud, Kenneth Kahn, Jim Kempf, Larry Masinter, Mark Stefik, Daniel L. Weinreb, and Jon L White. CONTENTS CONTENTS ................................................... ............ 3–2 Status of Document ................................................... ........... 3–5 Terminology ................................................... ................ 3–6 Introduction ................................................... ................ 3–7 Class Organization in the CLOS Kernel ............................................... 3–9 The Classes in the CLOS Kernel ................................................... 3–10 standard-class ................................................... ............ 3–11 forward-referenced-class ................................................... ..... 3–11 built-in-class ................................................... ............. 3–11 structure-class ................................................... ............ 3–12 funcallable-standard-class ................................................... .... 3–12 standard-slot-description ................................................... .... 3–12 standard-class-slot-description ................................................... 3–12 standard-method ................................................... .......... 3–12
    [Show full text]
  • Balancing the Eulisp Metaobject Protocol
    Balancing the EuLisp Metaob ject Proto col x y x z Harry Bretthauer and Harley Davis and Jurgen Kopp and Keith Playford x German National Research Center for Computer Science GMD PO Box W Sankt Augustin FRG y ILOG SA avenue Gallieni Gentilly France z Department of Mathematical Sciences University of Bath Bath BA AY UK techniques which can b e used to solve them Op en questions Abstract and unsolved problems are presented to direct future work The challenge for the metaob ject proto col designer is to bal One of the main problems is to nd a b etter balance ance the conicting demands of eciency simplicity and b etween expressiveness and ease of use on the one hand extensibili ty It is imp ossible to know all desired extensions and eciency on the other in advance some of them will require greater functionality Since the authors of this pap er and other memb ers while others require greater eciency In addition the pro of the EuLisp committee have b een engaged in the design to col itself must b e suciently simple that it can b e fully and implementation of an ob ject system with a metaob ject do cumented and understo o d by those who need to use it proto col for EuLisp Padget and Nuyens intended This pap er presents a metaob ject proto col for EuLisp to correct some of the p erceived aws in CLOS to sim which provides expressiveness by a multileveled proto col plify it without losing any of its p ower and to provide the and achieves eciency by static semantics for predened means to more easily implement it eciently The current metaob
    [Show full text]
  • A Metaobject Protocol for Fault-Tolerant CORBA Applications
    A Metaobject Protocol for Fault-Tolerant CORBA Applications Marc-Olivier Killijian*, Jean-Charles Fabre*, Juan-Carlos Ruiz-Garcia*, Shigeru Chiba** *LAAS-CNRS, 7 Avenue du Colonel Roche **Institute of Information Science and 31077 Toulouse cedex, France Electronics, University of Tsukuba, Tennodai, Tsukuba, Ibaraki 305-8573, Japan Abstract The corner stone of a fault-tolerant reflective The use of metalevel architectures for the architecture is the MOP. We thus propose a special implementation of fault-tolerant systems is today very purpose MOP to address the problems of general-purpose appealing. Nevertheless, all such fault-tolerant systems ones. We show that compile-time reflection is a good have used a general-purpose metaobject protocol (MOP) approach for developing a specialized runtime MOP. or are based on restricted reflective features of some The definition and the implementation of an object-oriented language. According to our past appropriate runtime metaobject protocol for implementing experience, we define in this paper a suitable metaobject fault tolerance into CORBA applications is the main protocol, called FT-MOP for building fault-tolerant contribution of the work reported in this paper. This systems. We explain how to realize a specialized runtime MOP, called FT-MOP (Fault Tolerance - MetaObject MOP using compile-time reflection. This MOP is CORBA Protocol), is sufficiently general to be used for other aims compliant: it enables the execution and the state evolution (mobility, adaptability, migration, security). FT-MOP of CORBA objects to be controlled and enables the fault provides a mean to attach dynamically fault tolerance tolerance metalevel to be developed as CORBA software. strategies to CORBA objects as CORBA metaobjects, enabling thus these strategies to be implemented as 1 .
    [Show full text]
  • Protocols What Are Protocols?
    Protocols What are Protocols? • A protocol is a set of possibly interacting functions. • Example: (defgeneric read-bytes (stream n)) (defgeneric read-byte (stream)) Possible Interactions • (defgeneric read-bytes (stream n)) (defgeneric read-byte (stream)) • Option 1: (defmethod read-bytes (stream n) (let ((array (make-array n))) (loop for i below n do (setf (aref array i) (read-byte stream))) array)) Possible Interactions • (defgeneric read-bytes (stream n)) (defgeneric read-byte (stream)) • Option 2: (defmethod read-byte (stream) (let ((array (read-bytes 1))) (aref array 0))) Possible Interactions • (defgeneric read-bytes (stream n)) (defgeneric read-byte (stream)) • Option 3: No interactions. (The two generic functions are independent.) • Why does it matter? You have to know what you can override and what effects overriding has. Protocols in CLOS • CLOS defines some protocols for its operators. make-instance • (defmethod make-instance (class &rest initargs) ... (let ((instance (apply #’allocate-instance class initargs))) (apply #’initialize-instance instance initargs) instance)) initialize-instance • (defmethod initialize-instance ((instance standard-object) &rest initargs) (apply #’shared-initialize instance t initargs)) Initialization Protocol • make-instance calls allocate-instance and then initialize-instance. • allocate-instance allocates storage. • initialize-instance calls shared-initialize. • shared-initialize assigns the slots. change-class • change-class modifies the object to be an instance of a different class and then calls update-instance-for-different-class. • update-instance-for-different-class calls shared-initialize. reinitialize-instance • reinitialize-instance calls shared-initialize. Class Redefinition • When a class is redefined, make-instances-obsolete may be called. • make-instances-obsolete ensures that update-instance-for-redefined-class is called for each instance.
    [Show full text]
  • Extending ODMG Metadata to Define External Schemas
    JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering ©JOT, 2003 Vol. 2, No. 2, March-April 2003 Extending ODMG Metadata to Define External Schemas Manuel Torres, Departamento de Lenguajes y Computación. University of Almeria, Spain José Samos, Departamento de Lenguajes y Sistemas Informáticos. University of Granada, Spain Abstract Given that ODMG 3.0 specifications do not address the definition of external schemas, we are developing an external schema definition methodology for ODMG databases. In this paper, an extension of ODMG metadata is proposed to support the definition of external schemas. In particular, metadata for derived classes and derived interfaces are defined, as well as some modifications to define inheritance relationships depending on the schema. The extension to ODMG metadata proposed in this paper maintains the structure of the ODMG schema repository as an object-oriented schema, and can be used by most of the existing external schema definition methodologies. The proposed extension is illustrated using our methodology. 1 INTRODUCTION One of the main drawbacks of object-oriented databases (OODB) was due to a lack of a standard for such databases, but with the emergence of the ODMG standard, this problem started to be solved. However, ODMG specifications do not address the definition of external schemas in ODMG databases. External schemas correspond to the view level of the well-known ANSI/SPARC architecture. In the ANSI/SPARC architecture, a database can be seen at three levels, known respectively as physical, logical, and view. For each level, there is a schema: internal, conceptual, and external.
    [Show full text]
  • Modelling Objects in PICT 1 Introduction
    Mo delling Ob jects in PICT JeanGuy Schneider Markus Lump e Software Comp osition Group IAM January Abstract For the development of presentday applications programming languages supp orting high order abstractions are needed These high order abstractions are called com p onents Since most of the currently available programming languages and systems fail to provide sucient supp ort for sp ecifying and implementing comp onents we are developing a new language suitable for software comp osition It is not clear how such a language will lo ok like what kind of abstractions it must supp ort and what kind of formal mo del it will b e based on Ob jectoriented programming languages address some of the needs of presentday applications and it is therefore obvious to integrate some of their concepts and abstractions in the language As a rst step towards such an integration we have to dene an ob ject mo del Since no generally accepted formal ob ject mo del exists we have chosen the calculus as a basis for mo delling In order to nd a suitable ob ject mo del we have built up an ob ject mo delling workbench for PICT an implementation of an asynchronous calculus In this work we dene a rst abstract ob ject mo del describ e several implementations of the ob ject mo del in PICT and discuss interesting features and p ossible extensions Keywords calculus PICT ob ject mo delling software comp osition CR Categories and Sub ject Descriptors D Programming Techniques Concurrent Programming D Programming Techniques Ob jectoriented Pro gramming D Software Engineering
    [Show full text]
  • Technical Report
    MetaJava - A Platform for Adaptable Operating-System Mechanisms Michael Golm, Jürgen Kleinöder April 1997 TR-I4-97-10 Technical Report Computer Science Department Operating Systems — IMMD IV Friedrich-Alexander-University Erlangen-Nürnberg, Germany Presented at the ECOOP 97 Workshop on Object-Orientation and Operating Systems, June 10, 1997, Jyväskylä, Finland MetaJava - A Platform for Adaptable Operating-System Mechanisms Michael Golm, Jürgen Kleinöder1 University of Erlangen-Nürnberg, Dept. of Computer Science IV Martensstr. 1, D-91058 Erlangen, Germany {golm, kleinoeder}@informatik.uni-erlangen.de Abstract to languages and run-time systems have been implemented 1 to support some of these mechanisms. But this solution does Fine-grained adaptable operating-system services can not meet the very diverse demands, different applications not be implemented with todays layered operating-system make on such mechanisms. Instead it is desirable to provide architectures. Structuring a system in base level and meta an application with means to control the implementation of level opens the implementation of operating-system ser- its run-time mechanismans and to add own modifications or vices. Operating-system services are implemented as meta extensions if necessary. Reflection is a fundamental concept objects and can be replaced by other meta objects if the to get influence on properties and implementation of the application object requires this. execution environment of a computing system. Smith’s work on 3-LISP [Smi82] was the first that con- 1 Introduction sidered reflection as essential part of the programming model. Maes [Mae87] studied reflection in object oriented This paper describes the MetaJava system, an extended systems. According to Maes reflection is the capability of a Java interpreter that allows structural and behavioral reflec- computational system to “reason about and act upon itself” tion.
    [Show full text]
  • The Glasshouse - a Reflective Container for Mobile Code
    The Glasshouse - A Reflective Container for Mobile Code Ian S. Welch Department of Computing University of Newcastle upon Tyne Email: [email protected] June 11, 2001 1 Introduction Mobile code has become mainstream, Java’s applets provide a familiar example. Other examples, where the code may be loaded from a local store but may have been provided by a third party, are Enterprise Java Beans [1] and Microsoft’s COM [2]. Here, compo- nents execute within a container that provides services to the component. This container and component programming model is very similar to mobile code architectures where mobile code is executed within some form of execution platform. In this position paper, I describe how the component and container model is re- lated to behavioural reflection and outline a proposal to build a reflective container for components called the Glasshouse that allows the use of intrusion-tolerant services, and supports some intrusion-tolerance for components. 2 Containers and Components Figure 1 shows a component and container framework. Components can represent mo- bile code or third party code that has been loaded from a local file store. In some instantiations of the framework, the dynamically loaded code comes from local file sys- tem and in others the dynamically loaded code can come from a remote location. The common idea is that code is loaded into a container where it executes. The compo- nent can then take advantage of local services provided by the container (for example, transactional support or security). The components do not have to explicitly invoke container services.
    [Show full text]
  • Method Combinators Didier Verna
    Method Combinators Didier Verna To cite this version: Didier Verna. Method Combinators. European Lisp Symposium, 2018, Marbella, Spain. hal- 01813488 HAL Id: hal-01813488 https://hal.archives-ouvertes.fr/hal-01813488 Submitted on 12 Jun 2018 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Method Combinators Didier Verna EPITA Research and Development Laboratory Le Kremlin-Bicêtre, France [email protected] ABSTRACT 1 INTRODUCTION In traditional object-oriented languages, the dynamic dispatch al- Common Lisp was the rst programming language equipped with gorithm is hardwired: for every polymorphic call, only the most an object-oriented (OO) layer to be standardized [16]. Although specic method is used. Clos, the Common Lisp Object System, in the lineage of traditional class-based OO languages such as goes beyond the traditional approach by providing an abstraction Smalltalk and later C++ and Java, Clos, the Common Lisp Ob- known as method combinations: when several methods are applica- ject System [2, 5, 7, 9], departs from those in several important ble, it is possible to select several of them, decide in which order ways. they will be called, and how to combine their results, essentially First of all, Clos oers native support for multiple dispatch [3, 4].
    [Show full text]
  • CLOS: Integrating Object-Oriented and Functional Programming
    CLOS: Integrating Object-Oriented and Functional Programming Richard P. Gabriel Jon L White Daniel G. Bobrow Lucid, Inc. Lucid, Inc. Xerox PARC May 3, 2004 CR Categories: D.3.0, D.3.2, D.3.3 Lisp has a long history as a functional language, where action is invoked by calling a procedure, and where procedural abstraction and encapsulation pro- vide convenient modularity boundaries. A number of attempts have been made to graft object-oriented programming into this framework without losing the es- sential character of Lisp—to include the benefits of data abstraction, extensible type classification, incremental operator definition, and code reuse through an inheritance hierarchy. CLOS—the Common Lisp Object System[2], which is an outcome of the ANSI standardization process for Common Lisp—represents a marriage of these two traditions. We explore the landscape in which the major object-oriented facilities exist, showing how the CLOS solution is effective within the two con- texts. 1 Incremental Definition of Operations A generic function, or polymorphic function as it is sometimes called, is one whose implementation depends on the types of its arguments. That is, the code that is executed for a particular set of arguments is mechanically determined by the types of the arguments. In strictly functional languages, an operation is defined by a single, mono- lithic piece of code; any argument-type conditionality is expressed as code ex- plicitly programmed in by the user. In contrast, the CLOS notion of generic functions supports automatic selection from among separately defined, type- specific implementational parts. Yet, from the client’s point of view, generic functions and traditional ordinary functions are called in the same way: The procedural abstraction barrier is still in force.
    [Show full text]
  • Bootstrapping Common Lisp Using Common Lisp Irène A
    Bootstrapping Common Lisp using Common Lisp Irène A. Durand, Robert Strandh To cite this version: Irène A. Durand, Robert Strandh. Bootstrapping Common Lisp using Common Lisp. EUROPEAN LISP SYMPOSIUM, Apr 2019, GENOVA, Italy. 10.5281/zenodo.2634314. hal-02417646 HAL Id: hal-02417646 https://hal.archives-ouvertes.fr/hal-02417646 Submitted on 18 Dec 2019 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Bootstrapping Common Lisp using Common Lisp Ir`eneDurand Robert Strandh [email protected] [email protected] LaBRI, University of Bordeaux Talence, France ABSTRACT ACM Reference Format: Some Common Lisp implementations evolve through careful Ir`eneDurand and Robert Strandh. 2019. Bootstrapping Common modifications to an existing image. Most of the remaining Lisp using Common Lisp. In Proceedings of the 12th European Lisp Symposium (ELS'19). ACM, New York, NY, USA, 8 pages. implementations are bootstrapped using some lower-level language, typically C. As far as we know, only SBCL is bootstrapped from source code written mainly in Common 1 INTRODUCTION Lisp. But, in most cases, there is no profound reason for using a language other than Common Lisp for creating a Common In this paper, by bootstrapping a Common Lisp system we Lisp system, though there are some annoying details that mean creating some target Common Lisp system by build- have to be dealt with.
    [Show full text]