DOCSLIB.ORG

Computational Reflection . Class Based Objectkented Languages

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Computational Reflection . Class Based Objectkented Languages Computational. Reflection Class based Objectkented Languages JacquesFERBER LAFORIA Universite Paris 6, T 45-46 4 place Jussieu 75252 Paris Cedex 5 France Email: [email protected] Abstract 1 Introduction This paper describes various models of computational After having been considered as a fascinating but rather reflection in class based object oriented language. Two sophisticated feature, reflection has become an important different approaches are covered: the meta-object approach issue in the field of computing architecture and language which supposes that every object can have a meta-object design [Smith 821 Ferber 861 p.Maes 87.b] Ferber 881 describing and monitoring its behavior, and the message [Watanabe & Yonezawa 881. Reflective systems have reification approach which describes a messageas an object. shown their practical interest for implementing systems, The me&object approach is discussed more fully showing because of their ability to represent the system, i.e. its that it is important to differentiate between structural functionalities and its implementation, within the system reflection and computational reflection. We will see that, itself. Some of the key features of such systems are their whereas classes and me&asses are very important for the capacity for: former, they cannot cope adequately with the later. Therefore we introduce a model of computational reflection - implementation description: allocation of where me&objects are instances of a class META-OBJECT entities, garbage collection, incremental extension or of one of its subclasses. and re-implementation of the whole system; Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, - monitoring entities of the language: the ACM copyright notice and the title of the publication and its date appear, inspection, analysis, and dynamic modification of and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee the code within the language itself; and/or specific permission. 0 1989 ACM 089791-333-7/89/0010/0317 $1.50 October 1-6, 1989 OOPSLA ‘89 Proceedings 317 - interfacing and debugging: implementation of 1.’ what is the nature of met&objects and/or of meta- programming tools within the language; communications, and what is their structure and behavior, - self-reorganization: learning abilities of the ii’ how is the handling of messages and lookup of system’s behavior, for an increase in consistency and methods described at the meta-level related to basic efficiency. messagepassing, iii’ when does the system uses meta-object and/or Object oriented languages (OOL) seem to be a major meta-communications. domain where reflection can easily be implemented, because of the distributed nature of data and procedure in objects. This paper introduces three models of computational However there have been just a few works on that subject, reflection in class based object oriented languages. It shows leading to two different model of reflection: that the so-called metackzsses which are very useful for structural reflection cannot deal correctly with 1 the first model advocated by P.Cointe [Cointe 883, computational reflection, i.e. they are not used at the concerns the reflective use of classes and metaclasses for computational meta level. implementing objects. In a pure class model, like OBJVLISP [Briot & Cointe 871, each entity is an instance The three models are: of a single class. Classes are instances of other classes, called metaclasses. This model allows for extension of the l the metaclass model which is based on an static part of OOL, i.e. the structural aspects of objects equivalence between the meta-object and the class of considered as implementation of abstract data types. an object. 2 the second model, introduced by P.Maes [Maes 87.a], l the specific metu-object model where meta-objects following Smiths work [Smith 821, is directed towards the are instances of a class META-OBJECT or of one of use of computational reflection within the object oriented its subclasses. programming (OOP) paradigm. This model is based on the fact that each object has its own me&object that represents l the meta-communication model which is based on all its otherwise implicit informations: its structure and its the reification of the message. way of handling messages. It has been shown that the use of meta-objects for buildind reflection in OOL allows for This paper describes the three models. All implementations the definition of new features not initially present in the are given in the OBJVLISP model of OOL. However, the system: multi-inheritance, daemons on accessof attributes, implementation is not specific and can be adapted to any interface programming, debugging tools, etc... [Maes 87.b] object oriented language using messagepassing as the basic However, this model has been defined in the context of the control structure. language KRS [Van Marcke 881, which does not support the class/instance model of traditionnal OOL such as SMALLTALK, CL0s [Michiel & Gabriel] or OBJVLISP. 2 Aspects of reflection When defining an reflective architecture, one has to answer 2.1 Domains and reflective equations three basic questions: Creating a reflective architectures is a way of effectively i what entities should be reified, i.e. transformed into relating the implicit entities of a computation domain Dn, something which can be manipulated at the meta called the basic level, into another computation domain level? Dn+I, called the meta-level. Each domain can serve both as ii how is the causal link (i.e. the relationship between a basic domain for an upper level, or as a meta-domain for a a lower and an upper level) implemented? . lower level, except the domain Do, made of referents, which 111 when does the system shifts up to a meta-level? can be used only as a basic level. In the domain of object oriented languages, where the only Models of reflection can easily be defined by ways of entities are objects and messages, these questions can be reflection equations, which express how entities and reformulated as follows: expressions of the basic level, are described at the meta- level. Thus, reflective equations act as semantic equations, i.e. they give the semantics of the lower levels in terms of 318 OOPSLA ‘89 Proceedings October 1-6, 1989 upper levels. For instance, in LISP, one can give the main 2.2 Reflection in Object reflection equation for expression evaluation: oriented languages mge]pK Dn= Ml[ (eval 'e B!l[pB M [K]) 1 Dn+l In 3-KRS [Maes 87.a], when an object 0 receives a message, it delegates the message to its me&object M-O. where p and K represent respectively the environment and This process is applied again until the system finds a meta- the continuation of the evaluation of the expression e, M is object called DEFAULT-META-OBJECT,which uses a basic a semantic function from Dn to Dn+l, and where ‘e, is the interpreter of messageswritten directly in LISP. data structure that representse. The traditional model of reflection is based on However, 3-KRS is not a class based OOL. When adapting interpretation. The domain Dn is made of a set of entities the 3-KRS style of reflection in the class/instance paradigm, and expressions, written in a language Ln, and of an one has to choose between different solutions: the meta- interpreter In which interprets those expressions. The object can be either the receiver’s class, as in the structural interpreter is written in a language Ln+l and is interpreted model of reflection advocated by P.Cointe ICointe.871, or by an In+1 interpreter. When the system is not reflective, an instance of a specific class, META-OBJECT (or an the language Ln+ I is radically different from Ln. For instance of one of its subclasses). In chapter 4 the two instance, if Ll is LISP, L2 could be a compiled language models will be presentedand discussed in details. like C or Pascal, L3 the machine language instruction set, Using a meta-object for reflection is not the only way for etc... implementing computational reflection: it is also possible In reflective architectures, there is a virtually infinite chain to reify the communication process. This leads to a of identical languages Li, the so-called reflective tower. somehow different view of reflection in OOL, which can This can be achieved because there is one interpreter, call it also be used for debugging and implementation purposes. In I’, written in a language L’ different from Li, which is used chapter 5, this model will be presented and compared to the to close the regression and replace the interpreter In at the preceding. highest level of computation needed. For instance, in 3-LISP [DesRivikes & Smith 841 , when the system encounters a reflective function at the level Dn, 3 ObjVlisp: the demonstration it shift up one level to Dn+l . There it starts a computation. language If there is a call to a reflective function, it goes one level higher, at level Dn+2, etc... until it finds a reflective In order to develop the three basic reflection models in class function which does not use any reflective functions. All based OOL, we will use OBJVLISP, a Ianguage whose non-reflective functions are interpreted by the interpreter I’, organization is based on structural reflection [Cointe 871. written in another language. Thus reflection can be Actually this language is not important in itself and will be implemented because there is no loop in the definition of used only for demonstration purposes. Many papers have reflective function. introduced the OBJVLISP syntax.
Load more

Recommended publications
  • Application of TRIE Data Structure and Corresponding Associative Algorithms for Process Optimization in GRID Environment
    Application of TRIE data structure and corresponding associative algorithms for process optimization in GRID environment V. V. Kashanskya, I. L. Kaftannikovb South Ural State University (National Research University), 76, Lenin prospekt, Chelyabinsk, 454080, Russia E-mail: a [email protected], b [email protected] Growing interest around different BOINC powered projects made volunteer GRID model widely used last years, arranging lots of computational resources in different environments. There are many revealed problems of Big Data and horizontally scalable multiuser systems. This paper provides an analysis of TRIE data structure and possibilities of its application in contemporary volunteer GRID networks, including routing (L3 OSI) and spe- cialized key-value storage engine (L7 OSI). The main goal is to show how TRIE mechanisms can influence de- livery process of the corresponding GRID environment resources and services at different layers of networking abstraction. The relevance of the optimization topic is ensured by the fact that with increasing data flow intensi- ty, the latency of the various linear algorithm based subsystems as well increases. This leads to the general ef- fects, such as unacceptably high transmission time and processing instability. Logically paper can be divided into three parts with summary. The first part provides definition of TRIE and asymptotic estimates of corresponding algorithms (searching, deletion, insertion). The second part is devoted to the problem of routing time reduction by applying TRIE data structure. In particular, we analyze Cisco IOS switching services based on Bitwise TRIE and 256 way TRIE data structures. The third part contains general BOINC architecture review and recommenda- tions for highly-loaded projects.
    [Show full text]
  • C Programming: Data Structures and Algorithms
    C Programming: Data Structures and Algorithms An introduction to elementary programming concepts in C Jack Straub, Instructor Version 2.07 DRAFT C Programming: Data Structures and Algorithms, Version 2.07 DRAFT C Programming: Data Structures and Algorithms Version 2.07 DRAFT Copyright © 1996 through 2006 by Jack Straub ii 08/12/08 C Programming: Data Structures and Algorithms, Version 2.07 DRAFT Table of Contents COURSE OVERVIEW ........................................................................................ IX 1. BASICS.................................................................................................... 13 1.1 Objectives ...................................................................................................................................... 13 1.2 Typedef .......................................................................................................................................... 13 1.2.1 Typedef and Portability ............................................................................................................. 13 1.2.2 Typedef and Structures .............................................................................................................. 14 1.2.3 Typedef and Functions .............................................................................................................. 14 1.3 Pointers and Arrays ..................................................................................................................... 16 1.4 Dynamic Memory Allocation .....................................................................................................
    [Show full text]
  • Objects and Classes in Python Documentation Release 0.1
    Objects and classes in Python Documentation Release 0.1 Jonathan Fine Sep 27, 2017 Contents 1 Decorators 2 1.1 The decorator syntax.........................................2 1.2 Bound methods............................................3 1.3 staticmethod() .........................................3 1.4 classmethod() ..........................................3 1.5 The call() decorator.......................................4 1.6 Nesting decorators..........................................4 1.7 Class decorators before Python 2.6.................................5 2 Constructing classes 6 2.1 The empty class...........................................6 3 dict_from_class() 8 3.1 The __dict__ of the empty class...................................8 3.2 Is the doc-string part of the body?..................................9 3.3 Definition of dict_from_class() ...............................9 4 property_from_class() 10 4.1 About properties........................................... 10 4.2 Definition of property_from_class() ............................ 11 4.3 Using property_from_class() ................................ 11 4.4 Unwanted keys............................................ 11 5 Deconstructing classes 13 6 type(name, bases, dict) 14 6.1 Constructing the empty class..................................... 14 6.2 Constructing any class........................................ 15 6.3 Specifying __doc__, __name__ and __module__.......................... 15 7 Subclassing int 16 7.1 Mutable and immutable types.................................... 16 7.2
    [Show full text]
  • Abstract Data Types
    Chapter 2 Abstract Data Types The second idea at the core of computer science, along with algorithms, is data. In a modern computer, data consists fundamentally of binary bits, but meaningful data is organized into primitive data types such as integer, real, and boolean and into more complex data structures such as arrays and binary trees. These data types and data structures always come along with associated operations that can be done on the data. For example, the 32-bit int data type is defined both by the fact that a value of type int consists of 32 binary bits but also by the fact that two int values can be added, subtracted, multiplied, compared, and so on. An array is defined both by the fact that it is a sequence of data items of the same basic type, but also by the fact that it is possible to directly access each of the positions in the list based on its numerical index. So the idea of a data type includes a specification of the possible values of that type together with the operations that can be performed on those values. An algorithm is an abstract idea, and a program is an implementation of an algorithm. Similarly, it is useful to be able to work with the abstract idea behind a data type or data structure, without getting bogged down in the implementation details. The abstraction in this case is called an \abstract data type." An abstract data type specifies the values of the type, but not how those values are represented as collections of bits, and it specifies operations on those values in terms of their inputs, outputs, and effects rather than as particular algorithms or program code.
    [Show full text]
  • The Pros of Cons: Programming with Pairs and Lists
    The Pros of cons: Programming with Pairs and Lists CS251 Programming Languages Spring 2016, Lyn Turbak Department of Computer Science Wellesley College Racket Values • booleans: #t, #f • numbers: – integers: 42, 0, -273 – raonals: 2/3, -251/17 – floang point (including scien3fic notaon): 98.6, -6.125, 3.141592653589793, 6.023e23 – complex: 3+2i, 17-23i, 4.5-1.4142i Note: some are exact, the rest are inexact. See docs. • strings: "cat", "CS251", "αβγ", "To be\nor not\nto be" • characters: #\a, #\A, #\5, #\space, #\tab, #\newline • anonymous func3ons: (lambda (a b) (+ a (* b c))) What about compound data? 5-2 cons Glues Two Values into a Pair A new kind of value: • pairs (a.k.a. cons cells): (cons v1 v2) e.g., In Racket, - (cons 17 42) type Command-\ to get λ char - (cons 3.14159 #t) - (cons "CS251" (λ (x) (* 2 x)) - (cons (cons 3 4.5) (cons #f #\a)) Can glue any number of values into a cons tree! 5-3 Box-and-pointer diagrams for cons trees (cons v1 v2) v1 v2 Conven3on: put “small” values (numbers, booleans, characters) inside a box, and draw a pointers to “large” values (func3ons, strings, pairs) outside a box. (cons (cons 17 (cons "cat" #\a)) (cons #t (λ (x) (* 2 x)))) 17 #t #\a (λ (x) (* 2 x)) "cat" 5-4 Evaluaon Rules for cons Big step seman3cs: e1 ↓ v1 e2 ↓ v2 (cons) (cons e1 e2) ↓ (cons v1 v2) Small-step seman3cs: (cons e1 e2) ⇒* (cons v1 e2); first evaluate e1 to v1 step-by-step ⇒* (cons v1 v2); then evaluate e2 to v2 step-by-step 5-5 cons evaluaon example (cons (cons (+ 1 2) (< 3 4)) (cons (> 5 6) (* 7 8))) ⇒ (cons (cons 3 (< 3 4))
    [Show full text]
  • Csci 658-01: Software Language Engineering Python 3 Reflexive
    CSci 658-01: Software Language Engineering Python 3 Reflexive Metaprogramming Chapter 3 H. Conrad Cunningham 4 May 2018 Contents 3 Decorators and Metaclasses 2 3.1 Basic Function-Level Debugging . .2 3.1.1 Motivating example . .2 3.1.2 Abstraction Principle, staying DRY . .3 3.1.3 Function decorators . .3 3.1.4 Constructing a debug decorator . .4 3.1.5 Using the debug decorator . .6 3.1.6 Case study review . .7 3.1.7 Variations . .7 3.1.7.1 Logging . .7 3.1.7.2 Optional disable . .8 3.2 Extended Function-Level Debugging . .8 3.2.1 Motivating example . .8 3.2.2 Decorators with arguments . .9 3.2.3 Prefix decorator . .9 3.2.4 Reformulated prefix decorator . 10 3.3 Class-Level Debugging . 12 3.3.1 Motivating example . 12 3.3.2 Class-level debugger . 12 3.3.3 Variation: Attribute access debugging . 14 3.4 Class Hierarchy Debugging . 16 3.4.1 Motivating example . 16 3.4.2 Review of objects and types . 17 3.4.3 Class definition process . 18 3.4.4 Changing the metaclass . 20 3.4.5 Debugging using a metaclass . 21 3.4.6 Why metaclasses? . 22 3.5 Chapter Summary . 23 1 3.6 Exercises . 23 3.7 Acknowledgements . 23 3.8 References . 24 3.9 Terms and Concepts . 24 Copyright (C) 2018, H. Conrad Cunningham Professor of Computer and Information Science University of Mississippi 211 Weir Hall P.O. Box 1848 University, MS 38677 (662) 915-5358 Note: This chapter adapts David Beazley’s debugly example presentation from his Python 3 Metaprogramming tutorial at PyCon’2013 [Beazley 2013a].
    [Show full text]
  • The Use of UML for Software Requirements Expression and Management
    The Use of UML for Software Requirements Expression and Management Alex Murray Ken Clark Jet Propulsion Laboratory Jet Propulsion Laboratory California Institute of Technology California Institute of Technology Pasadena, CA 91109 Pasadena, CA 91109 818-354-0111 818-393-6258 [email protected] [email protected] Abstract— It is common practice to write English-language 1. INTRODUCTION ”shall” statements to embody detailed software requirements in aerospace software applications. This paper explores the This work is being performed as part of the engineering of use of the UML language as a replacement for the English the flight software for the Laser Ranging Interferometer (LRI) language for this purpose. Among the advantages offered by the of the Gravity Recovery and Climate Experiment (GRACE) Unified Modeling Language (UML) is a high degree of clarity Follow-On (F-O) mission. However, rather than use the real and precision in the expression of domain concepts as well as project’s model to illustrate our approach in this paper, we architecture and design. Can this quality of UML be exploited have developed a separate, ”toy” model for use here, because for the definition of software requirements? this makes it easier to avoid getting bogged down in project details, and instead to focus on the technical approach to While expressing logical behavior, interface characteristics, requirements expression and management that is the subject timeliness constraints, and other constraints on software using UML is commonly done and relatively straight-forward, achiev- of this paper. ing the additional aspects of the expression and management of software requirements that stakeholders expect, especially There is one exception to this choice: we will describe our traceability, is far less so.
    [Show full text]
  • Data Structures, Buffers, and Interprocess Communication
    Data Structures, Buffers, and Interprocess Communication We’ve looked at several examples of interprocess communication involving the transfer of data from one process to another process. We know of three mechanisms that can be used for this transfer: - Files - Shared Memory - Message Passing The act of transferring data involves one process writing or sending a buffer, and another reading or receiving a buffer. Most of you seem to be getting the basic idea of sending and receiving data for IPC… it’s a lot like reading and writing to a file or stdin and stdout. What seems to be a little confusing though is HOW that data gets copied to a buffer for transmission, and HOW data gets copied out of a buffer after transmission. First… let’s look at a piece of data. typedef struct { char ticker[TICKER_SIZE]; double price; } item; . item next; . The data we want to focus on is “next”. “next” is an object of type “item”. “next” occupies memory in the process. What we’d like to do is send “next” from processA to processB via some kind of IPC. IPC Using File Streams If we were going to use good old C++ filestreams as the IPC mechanism, our code would look something like this to write the file: // processA is the sender… ofstream out; out.open(“myipcfile”); item next; strcpy(next.ticker,”ABC”); next.price = 55; out << next.ticker << “ “ << next.price << endl; out.close(); Notice that we didn’t do this: out << next << endl; Why? Because the “<<” operator doesn’t know what to do with an object of type “item”.
    [Show full text]
  • Metaclasses: Generative C++
    Metaclasses: Generative C++ Document Number: P0707 R3 Date: 2018-02-11 Reply-to: Herb Sutter ([email protected]) Audience: SG7, EWG Contents 1 Overview .............................................................................................................................................................2 2 Language: Metaclasses .......................................................................................................................................7 3 Library: Example metaclasses .......................................................................................................................... 18 4 Applying metaclasses: Qt moc and C++/WinRT .............................................................................................. 35 5 Alternatives for sourcedefinition transform syntax .................................................................................... 41 6 Alternatives for applying the transform .......................................................................................................... 43 7 FAQs ................................................................................................................................................................. 46 8 Revision history ............................................................................................................................................... 51 Major changes in R3: Switched to function-style declaration syntax per SG7 direction in Albuquerque (old: $class M new: constexpr void M(meta::type target,
    [Show full text]
  • Meta-Class Features for Large-Scale Object Categorization on a Budget
    Meta-Class Features for Large-Scale Object Categorization on a Budget Alessandro Bergamo Lorenzo Torresani Dartmouth College Hanover, NH, U.S.A. faleb, [email protected] Abstract cation accuracy over a predefined set of classes, and without consideration of the computational costs of the recognition. In this paper we introduce a novel image descriptor en- We believe that these two assumptions do not meet the abling accurate object categorization even with linear mod- requirements of modern applications of large-scale object els. Akin to the popular attribute descriptors, our feature categorization. For example, test-recognition efficiency is a vector comprises the outputs of a set of classifiers evaluated fundamental requirement to be able to scale object classi- on the image. However, unlike traditional attributes which fication to Web photo repositories, such as Flickr, which represent hand-selected object classes and predefined vi- are growing at rates of several millions new photos per sual properties, our features are learned automatically and day. Furthermore, while a fixed set of object classifiers can correspond to “abstract” categories, which we name meta- be used to annotate pictures with a set of predefined tags, classes. Each meta-class is a super-category obtained by the interactive nature of searching and browsing large im- grouping a set of object classes such that, collectively, they age collections calls for the ability to allow users to define are easy to distinguish from other sets of categories. By us- their own personal query categories to be recognized and ing “learnability” of the meta-classes as criterion for fea- retrieved from the database, ideally in real-time.
    [Show full text]
  • Subtyping Recursive Types
    ACM Transactions on Programming Languages and Systems, 15(4), pp. 575-631, 1993. Subtyping Recursive Types Roberto M. Amadio1 Luca Cardelli CNRS-CRIN, Nancy DEC, Systems Research Center Abstract We investigate the interactions of subtyping and recursive types, in a simply typed λ-calculus. The two fundamental questions here are whether two (recursive) types are in the subtype relation, and whether a term has a type. To address the first question, we relate various definitions of type equivalence and subtyping that are induced by a model, an ordering on infinite trees, an algorithm, and a set of type rules. We show soundness and completeness between the rules, the algorithm, and the tree semantics. We also prove soundness and a restricted form of completeness for the model. To address the second question, we show that to every pair of types in the subtype relation we can associate a term whose denotation is the uniquely determined coercion map between the two types. Moreover, we derive an algorithm that, when given a term with implicit coercions, can infer its least type whenever possible. 1This author's work has been supported in part by Digital Equipment Corporation and in part by the Stanford-CNR Collaboration Project. Page 1 Contents 1. Introduction 1.1 Types 1.2 Subtypes 1.3 Equality of Recursive Types 1.4 Subtyping of Recursive Types 1.5 Algorithm outline 1.6 Formal development 2. A Simply Typed λ-calculus with Recursive Types 2.1 Types 2.2 Terms 2.3 Equations 3. Tree Ordering 3.1 Subtyping Non-recursive Types 3.2 Folding and Unfolding 3.3 Tree Expansion 3.4 Finite Approximations 4.
    [Show full text]
  • Metaclass Functions: Generative C++
    Metaclass functions: Generative C++ Document Number: P0707 R4 Date: 2019-06-16 Reply-to: Herb Sutter ([email protected]) Audience: SG7, EWG Contents 1 Overview .............................................................................................................................................................2 2 Language: “Metaclass” functions .......................................................................................................................6 3 Library: Example metaclasses .......................................................................................................................... 18 4 Applying metaclasses: Qt moc and C++/WinRT .............................................................................................. 35 5 FAQs ................................................................................................................................................................. 41 R4: • Updated notes in §1.3 to track the current prototype, which now also has consteval support. • Added using metaclass function in the class body. Abstract The only way to make a language more powerful, but also make its programs simpler, is by abstraction: adding well-chosen abstractions that let programmers replace manual code patterns with saying directly what they mean. There are two major categories: Elevate coding patterns/idioms into new abstractions built into the language. For example, in current C++, range-for lets programmers directly declare “for each” loops with compiler support and enforcement.
    [Show full text]