DOCSLIB.ORG

Living It up with a Live Programming Language

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Living it up with a Live Programming Language Sean McDirmid Ecole´ Polytechnique Fed´ erale´ de Lausanne (EPFL) 1015 Lausanne, Switzerland sean.mcdirmid@epfl.ch Abstract eliminating verbose type annotations. Dynamic languages A dynamic language promotes ease of use through flexible also emphasize high-level programming models, often based typing, a focus on high-level programming, and by stream- on higher-order functions or objects, that reduce the amount lining the edit-compile-debug cycle. Live languages go be- of code needed to express a program. Together, flexible typ- yond dynamic languages with more ease of use features. A ing and high-level programming models support component live language supports live programming that provides pro- programming so that programmers can create feature-rich grammers with responsive and continuous feedback about programs with little code by reusing existing components. how their edits affect program execution. A live language Finally, dynamic language environments streamline the edit- is also based on high-level constructs such as declarative compile-debug cycle by either eliminating or hiding compi- rules so that programmers can write less code. A live lan- lation and by allowing code to be changed while a program guage could also provide programmers with responsive se- is running. For example, many Lisp [25], Smalltalk [12], and mantic feedback to enable time-saving services such as code Erlang [1] environments support hot swapping where a pro- completion. This paper describes the design of a textual live gram’s code can be updated without restarting. language that is based on reactive data-flow values known Can we design languages that are easier to use than ex- as signals and dynamic inheritance. Our language, Super- isting dynamic languages? For inspiration, look at visual Glue, supports live programming with responsive semantic languages such as Fabrik [15], LabVIEW [21], and spread- feedback, which we demonstrate with a working prototype. sheet languages such as Excel and Forms/3 [3], which are designed to be used by casual programmers, novices, and Categories and Subject Descriptors D.2.6 [Programming even end users. Visual languages are based on simple, of- Environments]: Interactive Environments—live program- ten declarative, programming models that heavily empha- ming; D.3.2 [Programming Languages]: Data-flow, Very size component reuse. For example, Apple’s Quartz Com- High-level, and Object-oriented Languages; D.3.3 [Lan- poser [17] supports the assembly of animation components guage Constructs and Features]: Inheritance—dynamic. through reactive data-flow connections that encapsulate General Terms Human Factors and Languages change-propagation details. The simple programming mod- els of visual languages also enable live programming, which 1. Introduction provides programmers with immediate and continuous feed- back about how their edits affect program execution. For Dynamic programming languages support rapid develop- example, editing a connection graph in Quartz Composer ment by reducing verbosity in both source code and the de- immediately changes the composed animation. Compared to velopment process. Although labeled as “dynamic” because live programming, the hot swapping supported by dynamic they often rely on dynamic typing, dynamic languages are languages is mushy: the effect of edited code on program best characterized by their emphasis of flexibility, concise- behavior is not apparent until the code is re-executed. For ness, and ease of development over performance and gen- example, editing the Smalltalk statement “w fill: red” to erality. Dynamic typing promotes flexibility by enforcing “w fill: blue” will not immediately re-color blue all wid- fewer restrictions on type compatibility and conciseness by gets that have been bound to w. In spite of their benefits, visual languages do not replace textual dynamic languages. For one thing, text can be writ- Permission to make digital or hard copies of all or part of this work for personal or ten more quickly [23]. More significantly, visual languages classroom use is granted without fee provided that copies are not made or distributed must deal with a scaling-up problem [4]: the ability to build for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute large programs is hindered by concrete visual notation that to lists, requires prior specific permission and/or a fee. does not easily support abstraction. Modern visual languages OOPSLA’07, October 21–25, 2007, Montreal,´ Quebec,´ Canada. solve the scaling up problem in a variety of ways; e.g., Copyright c 2007 ACM 978-1-59593-786-5/07/0010. $5.00 623 Forms/3 [3] allow for name-based cell referencing and data programming remains responsive, SuperGlue supports error abstraction through generic forms. Still, text’s natural sup- recovery where syntax, semantic, and execution errors are port for naming makes it more suitable for many abstraction- noted in the background while execution continues. The live heavy programming tasks. Also, the simple programming programming experience that is shown as a frame-expanded models that enable live programming in visual languages can movie1 in Figure 1 is narrated as follows: also be applied to textual languages. A live language is then a textual or visual language that supports live programming (a) The programmer types “port pacMan . Figure” to de- through a simple programming model. fine a pacMan signal that extends the game’s Figure class Support for textual naming in a live language is problem- so pacMan is drawn on the game’s canvas. Because a atic: how are programmers provided with responsive seman- shape for pacMan has not been specified, it is drawn by tic feedback about what names are valid? Semantic feedback default as a rectangle. speeds up the programming process by detecting typos early (b) The programmer types the extension “pacMan . Pie,” on and enabling services such as code completion, which al- which causes pacMan to extend the Pie class and be lows programmers to browse available resources. Program- drawn as a circle. The shape of pacMan is updated on mers are often deprived of responsive semantic feedback in screen as soon as the programmer types the “e” in Pie. dynamically-typed languages because names are difficult to (c) The programmer types the connection “pacMan.fill = resolve before run-time. Static typing that typically enables yellow,” causing this circle to be immediately colored semantic feedback is too verbose and inflexible to be used yellow. Through type inference, code completion can in a live language. Implicit typing would work better in a complete typing for .fill in pacMan. live language where inference provides responsive semantic feedback without type annotations. (d) The programmer types “pacMan.extent = 330.” As the This paper explores the design of a textual live language programmer types each character in “330,” pacMan’s ap- that reuses ideas from dynamic and visual languages along pears respectively as a 357, 327, and finally a 30 de- with a few new ideas. The language, SuperGlue, is based gree slice. The programmer than finishes this line with on a simple reactive data-flow programming model that is “+ (time % 30),” which causes pacMan’s mouth to close suited to building interactive programs out of existing com- continuously in a 30 degree motion. ponents. Components in SuperGlue are connected together The rest of this paper is organized as follows. Section 2 through signals into a data-flow graph. Being reactive, the lists live language design problems and how these problems values that flow across signal connections can change over are solved in SuperGlue. Section 3 describes how SuperGlue time, which eases the expression of interactive programs. supports live programming. Section 4 describes preliminary For scaling purposes, signals extend classes through dy- experience on SuperGlue’s use in developing a simple game. namic inheritance, where what classes a signal extends can Section 5 presents related work and Section 6 concludes. change at run time. Signals and dynamic inheritance seam- lessly support live programming by masquerading edits as 2. Language Design programmatic changes in the program’s mutable execution state. Unlike Self [29] and like Cecil [6], dynamic inheri- SuperGlue is based on the data-flow programming model tance in SuperGlue is based on declarative predicates [7], that was originally introduced by Karp and Miller [16] to which is very compatible with a reactive data-flow model. deal with concurrency through a graph program represen- Because class extensions are declarative, type inference can tation. Even without considering concurrency, the data-flow provide programmers with responsive semantic feedback. model is appealing to live languages because all computa- Dependent typing improves type inference so that type an- tional dependencies are encoded explicitly. The data-flow notations are unnecessary. model by itself does not scale: non-trivial programs involve a Previous work [20] introduces SuperGlue’s support for large or unbounded number of data-flow connections that are object-oriented signals, and shows how this support eases tedious or impossible to express individually. For this rea- the construction of interactive programs. This paper expands son, SuperGlue augments its data-flow model with object- on this work by augmenting SuperGlue with dynamic inher- oriented constructs. As a brief overview, SuperGlue consists itance, which significantly simplifies the language, and live of the following constructs: programming. Figure 1 shows how live programming occurs – Signals, which are data-flow values that facilitate inter- in a working Eclipse-based prototype. In this paper, we use component communication. Signals are objects that ex- a PacMan-like game as a running example. A program is tend classes, are connected to other signals, and contain edited freely as text in the upper half of the programming signals defined in their extended classes. Signals are de- environment while the execution is shown in the lower half.
Recommended publications
  • MANNING Greenwich (74° W

    MANNING Greenwich (74° W

    Object Oriented Perl Object Oriented Perl DAMIAN CONWAY MANNING Greenwich (74° w. long.) For electronic browsing and ordering of this and other Manning books, visit http://www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact: Special Sales Department Manning Publications Co. 32 Lafayette Place Fax: (203) 661-9018 Greenwich, CT 06830 email: [email protected] ©2000 by Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Library of Congress Cataloging-in-Publication Data Conway, Damian, 1964- Object oriented Perl / Damian Conway. p. cm. includes bibliographical references. ISBN 1-884777-79-1 (alk. paper) 1. Object-oriented programming (Computer science) 2. Perl (Computer program language) I. Title. QA76.64.C639 1999 005.13'3--dc21 99-27793 CIP Manning Publications Co. Copyeditor: Adrianne Harun 32 Lafayette
  • A Comparative Study on the Effect of Multiple Inheritance Mechanism in Java, C++, and Python on Complexity and Reusability of Code

    A Comparative Study on the Effect of Multiple Inheritance Mechanism in Java, C++, and Python on Complexity and Reusability of Code

    (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 8, No. 6, 2017 A Comparative Study on the Effect of Multiple Inheritance Mechanism in Java, C++, and Python on Complexity and Reusability of Code Fawzi Albalooshi Amjad Mahmood Department of Computer Science Department of Computer Science University of Bahrain University of Bahrain Kingdom of Bahrain Kingdom of Bahrain Abstract—Two of the fundamental uses of generalization in Booch, there are two problems associated with multiple object-oriented software development are the reusability of code inheritance and they are how to deal with name collisions from and better structuring of the description of objects. Multiple super classes, and how to handle repeated inheritance. He inheritance is one of the important features of object-oriented presents solutions to these two problems. Other researchers [4] methodologies which enables developers to combine concepts and suggest that there is a real need for multiple inheritance for increase the reusability of the resulting software. However, efficient object implementation. They justify their claim multiple inheritance is implemented differently in commonly referring to the lack of multiple subtyping in the ADA 95 used programming languages. In this paper, we use Chidamber revision which was considered as a deficiency that was and Kemerer (CK) metrics to study the complexity and rectified in the newer version [5]. It is clear that multiple reusability of multiple inheritance as implemented in Python, inheritance is a fundamental concept in object-orientation. The Java, and C++. The analysis of results suggests that out of the three languages investigated Python and C++ offer better ability to incorporate multiple inheritance in system design and reusability of software when using multiple inheritance, whereas implementation will better structure the description of objects Java has major deficiencies when implementing multiple modeling, their natural status and enabling further code reuse inheritance resulting in poor structure of objects.
  • Mixins and Traits

    Mixins and Traits

    ◦ ◦◦◦ TECHNISCHE UNIVERSITAT¨ MUNCHEN¨ ◦◦◦◦ ◦ ◦ ◦◦◦ ◦◦◦◦ ¨ ¨ ◦ ◦◦ FAKULTAT FUR INFORMATIK Programming Languages Mixins and Traits Dr. Michael Petter Winter 2016/17 What advanced techiques are there besides multiple implementation inheritance? Outline Design Problems Cons of Implementation Inheritance 1 Inheritance vs Aggregation 1 2 (De-)Composition Problems Lack of finegrained Control 2 Inappropriate Hierarchies Inheritance in Detail A Focus on Traits 1 A Model for single inheritance 1 2 Inheritance Calculus with Separation of Composition and Inheritance Expressions Modeling 2 3 Modeling Mixins Trait Calculus Mixins in Languages Traits in Languages 1 (Virtual) Extension Methods 1 Simulating Mixins 2 Squeak 2 Native Mixins Reusability ≡ Inheritance? Codesharing in Object Oriented Systems is often inheritance-centric. Inheritance itself comes in different flavours: I single inheritance I multiple inheritance All flavours of inheritance tackle problems of decomposition and composition The Adventure Game Door ShortDoor LockedDoor canPass(Person p) canOpen(Person p) ? ShortLockedDoor canOpen(Person p) canPass(Person p) The Adventure Game Door <interface>Doorlike canPass(Person p) canOpen(Person p) Short canPass(Person p) Locked canOpen(Person p) ShortLockedDoor ! Aggregation & S.-Inheritance Door must explicitely provide canOpen(Person p) chaining canPass(Person p) Doorlike must anticipate wrappers ) Multiple Inheritance X The Wrapper FileStream SocketStream read() read() write() write() ? SynchRW acquireLock() releaseLock() ! Inappropriate Hierarchies
  • Fujitsu PCI Expansion Unit

    Fujitsu PCI Expansion Unit

    PCI Expansion Unit The PCI Expansion Unit—an I/O expansion option for Oracle’s Fujitsu SPARC M12 and Fujitsu M10 family of servers—meets demands for applications requiring extensive scalability, mission-critical levels of availability, and Key Features seamless data center integration. The PCI Supports the Fujitsu SPARC M12 and Fujitsu M10 family of servers Expansion Unit takes maximum advantage of Provides 11 PCIe 3.0 slots in a small 2U form factor the high I/O bandwidth of Fujitsu SPARC M12 Powers on and off in synchronization with the power status of Fujitsu and Fujitsu M10 servers. SPARC M12 and Fujitsu M10 servers Enables hot swapping of PCIe cards, power supplies, and fans Monitored and controlled from the XSCF System Monitoring Function of the Fujitsu SPARC M12 and Fujitsu M10 servers Configured with 1 + 1 power supply PRODUCT OVERVIEW redundancy and supports a dual Perfectly suited for Fujitsu SPARC servers, the PCI Expansion Unit offers significant power feed configuration I/O adapter expandability. One or more PCI Expansion Units can be connected to both Fujitsu SPARC M12 and Fujitsu M10 servers, providing connectivity of up to 11 additional PCI Express (PCIe) slots per PCI Expansion Unit in a space-saving rackmount chassis (2U). PCIe generation 3 is supported by the PCI Expansion Unit. Easy Monitoring and Control from Fujitsu SPARC Servers The PCI Expansion Unit can be easily monitored and controlled in conjunction with the XSCF (eXtended System Control Facility) system monitoring function of Fujitsu SPARC servers. PCI Expansion Units power on and off in synchronization with the power status of Fujitsu SPARC servers.
  • System Support for Online Reconfiguration

    System Support for Online Reconfiguration

    System Support for Online Reconfiguration ¡ ¡ ¢ Craig A. N. Soules Jonathan Appavoo Kevin Hui Robert W. Wisniewski ¢ ¢ ¡ Dilma Da Silva Gregory R. Ganger Orran Krieger Michael Stumm ¢ ¢ ¢ ¢ Marc Auslander Michal Ostrowski Bryan Rosenburg Jimi Xenidis Abstract Request Response Profiler LRU Online reconfiguration provides a way to extend and re- place active operating system components. This pro- vides administrators, developers, applications, and the (a) After profiler is interposed around the page manager. system itself with a way to update code, adapt to chang- ing workloads, pinpoint performance problems, and per- form a variety of other tasks while the system is running. Request With generic support for interposition and hot-swapping, Response LRU FIFO a system allows active components to be wrapped with additional functionality or replaced with different im- (b) LRU page manager before hot-swap with FIFO. plementations that have the same interfaces. This pa- per describes support for online reconfiguration in the Request K42 operating system and our initial experiences us- Response FIFO ing it. It describes four base capabilities that are com- bined to implement generic support for interposition and (c) After FIFO page manager is fully swapped. hot-swapping. As examples of its utility, the paper de- scribes some performance enhancements that have been Figure 1: Online reconfiguration. This figure shows two online re- achieved with K42’s online reconfiguration mechanisms configuration mechanisms: interposition and hot-swapping. (a) shows including adaptive algorithms, common case optimiza- an LRU page manager and an interposed profiler that can watch the tions, and workload specific specializations. component’s calls/returns to see how it is performing.
  • Mixin-Based Programming in C++1

    Mixin-Based Programming in C++1

    Mixin-Based Programming in C++1 Yannis Smaragdakis Don Batory College of Computing Department of Computer Sciences Georgia Institute of Technology The University of Texas at Austin Atlanta, GA 30332 Austin, Texas 78712 [email protected] [email protected] Abstract. Combinations of C++ features, like inheritance, templates, and class nesting, allow for the expression of powerful component patterns. In particular, research has demonstrated that, using C++ mixin classes, one can express lay- ered component-based designs concisely with efficient implementations. In this paper, we discuss pragmatic issues related to component-based programming using C++ mixins. We explain surprising interactions of C++ features and poli- cies that sometimes complicate mixin implementations, while other times enable additional functionality without extra effort. 1 Introduction Large software artifacts are arguably among the most complex products of human intellect. The complexity of software has led to implementation methodologies that divide a problem into manageable parts and compose the parts to form the final prod- uct. Several research efforts have argued that C++ templates (a powerful parameteriza- tion mechanism) can be used to perform this division elegantly. In particular, the work of VanHilst and Notkin [29][30][31] showed how one can implement collaboration-based (or role-based) designs using a certain templatized class pattern, known as a mixin class (or just mixin). Compared to other techniques (e.g., a straightforward use of application frameworks [17]) the VanHilst and Notkin method yields less redundancy and reusable components that reflect the structure of the design. At the same time, unnecessary dynamic binding can be eliminated, result- ing into more efficient implementations.
  • Nexto Series

    Nexto Series

    Technical Characteristics Nexto Series Doc Code: CE114000 Revision: I Nexto Series Programmable Logic Controller Nexto Series is a powerful and complete Programmable Logic Controllers (PLCs) series with exclusive and innovative features, targeted for covering control systems requirements from medium to large applications or high performance industrial machines. Nexto Series architecture provides a wide range of input and output modules. These modules, combined with a powerful 32-bit processor and a high-speed-Ethernet-based backplane, cover many user applications, such as high-speed machinery control, complex distributed and redundant process applications or even large I/O systems for building automation. Besides, it delivers modules for motion control, communication and interfaces to the most popular fieldbuses, among other features. Nexto Series architecture uses a state-of-the-art high-speed Ethernet backplane bus technology, which allows input, output and processed information to be shared among all modules within the system. The I/O modules can be easily distributed in the field. It can be used local as well as remote I/Os without any loss in performance. In addition, Nexto Series brings a complete tool for programming, configuration, simulation and debugging user application: MasterTool IEC XE. MasterTool IEC XE is flexible and easy to use software that provides the six programming languages defined by IEC 61131-3 standard: Structured Text (ST), Sequential Function Chart (SFC), Function Block Diagram (FBD), Ladder Diagram (LD), Instruction List (IL) and Continuous Function Chart (CFC). MasteTool IEC XE allows the use of different languages on the same application, providing to the user a powerful way to organize the application and to reuse codes used in previous applications.
  • Comp 411 Principles of Programming Languages Lecture 19 Semantics of OO Languages

    Comp 411 Principles of Programming Languages Lecture 19 Semantics of OO Languages

    Comp 411 Principles of Programming Languages Lecture 19 Semantics of OO Languages Corky Cartwright Mar 10-19, 2021 Overview I • In OO languages, OO data values (except for designated non-OO types) are special records [structures] (finite mappings from names to values). In OO parlance, the components of record are called members. • Some members of an object may be functions called methods. Methods take this (the object in question) as an implicit parameter. Some OO languages like Java also support static methods that do not depend on this; these methods have no implicit parameters. In efficient OO language implementations, method members are shared since they are the same for all instances of a class, but this sharing is an optimization in statically typed OO languages since the collection of methods in a class is immutable during program evaluation (computation). • A method (instance method in Java) can only be invoked on an object (the receiver, an implicit parameter). Additional parameters are optional, depending on whether the method expects them. This invocation process is called dynamic dispatch because the executed code is literally extracted from the object: the code invoked at a call site depends on the value of the receiver, which can change with each execution of the call. • A language with objects is OO if it supports dynamic dispatch (discussed in more detail in Overview II & III) and inheritance, an explicit taxonomy for classifying objects based on their members and class names where superclass/parent methods are inherited unless overridden. • In single inheritance, this taxonomy forms a tree; • In multiple inheritance, it forms a rooted DAG (directed acyclic graph) where the root class is the universal class (Object in Java).
  • USB 3.0 to SATA 2.5" Tool-Less Enclosure Quick Installation Guide

    USB 3.0 to SATA 2.5" Tool-Less Enclosure Quick Installation Guide

    USB 3.0 to SATA 2.5" Tool-less Enclosure Quick Installation Guide Introduction The USB 3.0 to SATA 2.5" Tool-less Enclosure is designed to work USB equipped computers. This enclosure provides large capacity mobile storage using 2.5" SATA hard disk drives through hot-swapping USB 3.0 interface. Key Features and Benefits • Quickly adds more storage space to your USB-enabled PC (USB 3.0 recommended) • Supports USB 3.0 data transfer rate up to 5Gb/s • Tool-less design and no driver installation required • Supports up to 4TB hard disk capacity 04-0790B 1 Note: For maximum data throughput, use a SATA 3Gb/s hard disk with the enclosure and connect to a fully functional USB 3.0 port. System Requirements • Notebook or desktop PC with an available USB 2.0/3.0 port (USB 3.0 recommended) • Windows® 8 (32-/64-bit) / 7 (32-/64-bit) / Vista (32-/64-bit) / XP (32-/64-bit) / Server 2003 & 2008 (32-/64-bit) / Server 2008 R2 Package Contents • USB 3.0 to SATA 2.5" Tool-less Enclosure • USB 3.0 Y-split (data & power) cable • 2 Sponges (optional) • Quick installation guide 2 Layout Top cover USB 3.0 micro-B connector Bottom cover Power/Activity LED Slider to release the cases Figure 1: Back Panel Layout USB 3.0 Y-split Cable Type-A power (white) Type-A data (blue) micro-B Figure 2: USB 3.0 Y-split Cable Connectors 3 Power and Activity LED The LED indicator illuminates when the enclosure is connected and powered up.
  • Honeywell's Next Generation Plcs Powerful, Compact, Versatile, Open Network

    Honeywell's Next Generation Plcs Powerful, Compact, Versatile, Open Network

    Programmable Logic Controllers MasterLogic-200 Honeywell's next generation PLCs Powerful, compact, versatile, open network Programmable Logic Controllers MasterLogic-200 · Powerful & versatile · Scalable & modular · Compact pocket-size modules · CPU redundancy, power supply redundancy, network redundancy · Range of I/O modules-digital (source/sink,transistor/relay),analog (voltage/current) · Special modules-High Speed Counter, Position Control, RTD, Thermocouple · Open network-Profibus-DP, DeviceNet, Fast Ethernet, Modbus · Dedicated peer-to-peer networking of PLCs · Large I/O capacity and Remote I/O Contents Overview 4 Overview Introduction System Architecture 8 CPU & System configuration General Specifications CPU Specifications Highlights Introduction Network Fast Ethernet(FEnet) 15 Serial Communication(Snet) Profibus-DP(Pnet) DeviceNet(Dnet) Digital I/O Modules Input/Output Modules 20 Position Control Modules Analog I/O Modules Smart I/O(s) Thermocouple Module RTD Module High Speed Counter Modules Key Features Software 29 Project Management Online Functions Maintenance & Troubleshooting Monitoring PLC Event History Program Navigation & Editing Program Ease Simulation System Requirements SoftMaster-NM (Network setup & diagnostics) Special Interface Special Interface with Experion 37 PKS & Experion Vista MasterLogic-50 Other Related Products Master Panel 38 HCiX Series Product List 39 Product List Overview Introduction Key Features · Powerful & versatile processors - High speed i.e. (28ns/step, flash memory, hot-swapping) · CPU redundancy
  • Multiple Inheritance and the Resolution of Inheritance Conflicts

    Multiple Inheritance and the Resolution of Inheritance Conflicts

    JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering ©JOT, 2005 Vol. 4, No.2, March-April 2005 The Theory of Classification Part 17: Multiple Inheritance and the Resolution of Inheritance Conflicts Anthony J H Simons, Department of Computer Science, University of Sheffield, Regent Court, 211 Portobello Street, Sheffield S1 4DP, UK 1 INTRODUCTION This is the seventeenth article in a regular series on object-oriented theory for non- specialists. Using a second-order λ-calculus model, we have previously modelled the notion of inheritance as a short-hand mechanism for defining subclasses by extending superclass definitions. Initially, we considered the inheritance of type [1] and implementation [2] separately, but later combined both of these in a model of typed inheritance [3]. By simplifying the short-hand inheritance expressions, we showed how these are equivalent to canonical class definitions. We also showed how classes derived by inheritance are type compatible with their superclass. Further aspects of inheritance have included method combination [4], mixin inheritance [5] and inheritance among generic classes [6]. Most recently, we re-examined the ⊕ inheritance operator [7], to show how extending a class definition (the intension of a class) has the effect of restricting the set of objects that belong to the class (the extension of the class). We also added a type constraint to the ⊕ operator, to restrict the types of fields that may legally be combined with a base class to yield a subclass. By varying the form of this constraint, we modelled the typing of inheritance in Java, Eiffel, C++ and Smalltalk.
  • Providing Dynamic Update in an Operating System

    Providing Dynamic Update in an Operating System

    Providing Dynamic Update in an Operating System Andrew Baumann, Gernot Heiser University of New South Wales & National ICT Australia Jonathan Appavoo, Dilma Da Silva, Orran Krieger, Robert W. Wisniewski IBM T.J. Watson Research Center Jeremy Kerr IBM Linux Technology Center Abstract Dynamic update [26] is used to avoid such downtime. It involves on-the-fly application of software updates to Dynamic update is a mechanism that allows software a running system without loss of service. The increased updates and patches to be applied to a running system unplanned down-time of computing infrastructure to ap- without loss of service or down-time. Operating systems ply updates, combined with the demand for continuous would benefit from dynamic update, but place unique de- availability, provides strong motivation to investigate dy- mands on any implementation of such features. These namic update techniques for operating systems. demands stem from the event-driven nature of operating In addition to the above mentioned impact on avail- systems, from their restricted run-time execution envi- ability, dynamically updatable systems have other bene- ronment, and from their role in simultaneously servicing fits. Such systems provide a good prototyping environ- multiple clients. ment. They allow, for example, a new page replacement, We have implemented a dynamic update mechanism file system, or network policy to be tested without re- in the K42 research operating system, and tested it us- booting. Further, in more mature systems such as main- ing previous modifications of the system by kernel de- frames, some user constraints prevent the system from velopers. Our system supports updates changing both ever being shutdown.