DOCSLIB.ORG

The Code of Many Colors: Semi-Automated Reasoning About Multi-Thread Policy for Java

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Code of Many Colors: Semi-Automated Reasoning About Multi-Thread Policy for Java The Code of Many Colors: Semi-automated Reasoning about Multi-Thread Policy for Java Dean F. Sutherland CMU-ISR-08-112 May 2008 School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Thesis Committee: William L. Scherlis, Chair Jonathan Aldrich Stephen Brookes Eric Nyberg Guy L. Steele, Jr., Sun Microsystems Laboratories Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy. Copyright c 2008 Dean F. Sutherland ! This material is based upon work supported by the following grants: NASA: NCC2-1298 and NNA05C530A; Lockheed Martin: RRMHS1798; ARO: DAAD190210389; IBM Eclipse: IC-5010. The views and conclusions contained in this document are those of the author and should not be interpreted as representing the official policies, either expressed or implied of the sponsor or the U.S. government. Keywords: Java, Program evolution, Static analysis, Race Conditions, Multi-threaded programming, Design Intent, Concurrency, Program assurance For Libby, who has spent far too many years providing front-line support for me and for this work. She’s in serious danger of being recognized as the world’s finest spouse. Also for Ivan, who has spent too many years and too many dollars providing financial support for my graduate schooling. I couldn’t have done it without either of you. iv Abstract Concurrent programming has proven to be difficult. One cause of this difficulty is that the rel- evant thread usage policy seldom appears either in documents or code comments. A second dif- ficulty is that thread usage policy—even when it is known—imposes widespread consequences on the code to be written. Finally, finding and removing concurrency faults in existing code is hard. This thesis introduces thread coloring, a language of discourse useful for concise expression of and reasoning about intended thread usage policies in a wide variety of code. Thread coloring addresses a range of concurrency issues—assuring single-thread access, identifying possibly- shared data regions and localizing knowledge about roles for threads—that have not previously been comprehensively addressed. Using this language, programmers can model design intent about relationships among the roles of threads with respect to segments of executable code and also with respect to shared state. Programmers formally link the model with their code by ex- pressing the model as annotations in that code. This thesis describes a prototype analysis tool, integrated into an integrated development environment, and its use in case studies to demonstrate that thread coloring is a feasible and practicable approach to expressing and understanding thread usage policies, including complex ones. The tool analyzes consistency between the expressed model and the as-written code, and notifies programmers of discrepancies between them. The case studies use published code to demonstrate that developers can express useful models, identify concurrency faults and assure policy compliance. The thesis includes a demonstration of scaling to a medium-sized program of 140KSLOC and a demonstration of the potential to scale to much larger programs and sup- port composition among analysis results for separately developed components. By limiting the problem scope to thread usage policy, the prototype implementation requires one hundred times fewer annotations than are needed for full functional correctness—6.3 annotations per KSLOC, potentially reduceable in future by another order of magnitude. This thesis provides five primary contributions to software engineering. First, it provides a language that developers can use to express thread usage policies. Second, it provides a sys- tematic way to improve code quality by assuring that as-written code complies with expressed thread usage policy. Third, it uses a new combination of preexisting techniques to reduce the effort required to express models to very low levels. Fourth, it demonstrates techniques that per- mit the analysis to operate on very large programs—millions of lines of code appear to be within reach. Finally, it demonstrates techniques that permit straightforward and reliable incremental recomputation of results after a program change. vi Acknowledgments Every member of the Fluid group provided essential support and encouragement throughout my research. Edwin Chan kept the software working and pulled together whatever infrastructure I needed. John Tang Boyland built the IR and much of the other infrastructure. Aaron Green- house showed me how to write analyses that work with the IR. John and Aaron wrote the effects analysis that provides my connection with data. Tim Halloran got us hooked into Eclipse, and provided the Drop–Sea TMS. Elissa Newman helped me understand how to visualize my analy- sis. Bill Scherlis pointed us all in the right direction, provided sage advice as needed, and kept the funding flowing. I certainly couldn’t have done it without you. Jonathan Aldrich spent endless hours helping me get my head around small-step semantics. He also provided a valuable sounding board about many different technical issues, especially during the design of the module system. Thanks for your patience and help. Several outside readers spent way too much time reading drafts of dissertation chapters and telling me what I’d done wrong. I owe many thanks to Aaron Greenhouse, Daniel V. Klein, Joseph M. Newcomer, and Ivan E. Sutherland. I especially want to thank Elizabeth Sutherland for her tireless efforts reading, critiquing and editing my dissertation. Without her efforts I would still have four different names for the color environment, a modules chapter on the brink of incomprehensibility, and a guided tour that loses readers at every turn. The members of my thesis committee provided critical feedback about my research and my dissertation. They also provided exceedingly prompt turn-around on a dissertation that really should have been out weeks before it actually was. Thank you all, for your valuable input. viii Contents 1 Introduction 1 1.1 Vision . 1 1.2 Thread usage policy . 1 1.3 The problem: policy-based concurrency is difficult to implement correctly . 2 1.3.1 Respecting thread usage policy . 3 1.3.2 Repairing thread usage policy faults . 3 1.3.3 Thread usage policy knowledge . 4 1.4 Our approach: Thread coloring . 4 1.4.1 Formal Language . 5 1.4.2 Analysis . 6 1.5 Assessing thread coloring . 6 1.5.1 Tool . 6 1.5.2 Criteria for practicability . 7 1.6 Value of thread coloring in development . 10 1.7 Thesis Statement . 10 1.7.1 Outline of the dissertation . 11 1.7.2 Modules . 12 2 Informal presentation of the coloring model 15 2.1 Introduction . 15 2.2 Why use thread coloring? . 15 2.2.1 The Fluid solution . 16 2.3 Guided tour of thread coloring . 17 2.3.1 Modules . 17 2.3.2 Color names . 19 2.3.3 Color constraints . 20 2.3.4 Consistency Checking . 21 2.3.5 Unconstrained code . 22 2.3.6 Running example . 23 2.3.7 Color inheritance . 24 2.3.8 Running example . 25 2.3.9 Granting colors . 25 2.3.10 Scoped promises . 28 2.3.11 Running Example . 29 2.3.12 Issues previously glossed-over . 29 2.3.13 Running example . 30 2.3.14 Coloring data . 31 2.4 Design intent at scale . 33 2.4.1 Scaling design intent for large programs . 34 2.4.2 Scaling design intent for many thread roles . 34 2.4.3 Fundamentally complex threading models . 35 ix 3 Modules 37 3.1 Introduction . 37 3.2 Why use modules? . 37 3.2.1 Software developers and managers . 37 3.2.2 Analysis developers . 39 3.3 Designing the Fluid module system . 40 3.3.1 Why design yet another module system? . 40 3.3.2 Design criteria . 40 3.4 Design concept, rationale & realization . 43 3.4.1 Terminology . 44 3.4.2 Modules from thirty-thousand feet . 45 3.4.3 Local visibility rule . 45 3.4.4 Hierarchy . 45 3.4.5 In/Out visibility control . 53 3.4.6 Non-tree-shaped module hierarchy . 56 3.4.7 Support for existing code . 58 3.5 Case study and validation . 61 3.5.1 Analyses that take advantage of the Fluid module system . 61 3.5.2 Electric 8.01 case study . 62 3.6 Comparative analysis . 66 3.6.1 Other module systems . 66 3.6.2 Module system attributes . 68 3.6.3 What’s different about the Fluid module system? . 72 3.7 Future Work . 72 4 Case studies 75 4.1 Introduction . 75 4.2 Realism and practicability . 76 4.3 GraphLayout case study . 76 4.3.1 The Application . 78 4.3.2 Case study details . 78 4.4 Sky View Café case study . 84 4.4.1 The application . 85 4.4.2 Case study details . ..
Load more

Recommended publications
  • Ece351 Lab Manual
    DEREK RAYSIDE & ECE351 STAFF ECE351 LAB MANUAL UNIVERSITYOFWATERLOO 2 derek rayside & ece351 staff Copyright © 2014 Derek Rayside & ECE351 Staff Compiled March 6, 2014 acknowledgements: • Prof Paul Ward suggested that we look into something with vhdl to have synergy with ece327. • Prof Mark Aagaard, as the ece327 instructor, consulted throughout the development of this material. • Prof Patrick Lam generously shared his material from the last offering of ece251. • Zhengfang (Alex) Duanmu & Lingyun (Luke) Li [1b Elec] wrote solutions to most labs in txl. • Jiantong (David) Gao & Rui (Ray) Kong [3b Comp] wrote solutions to the vhdl labs in antlr. • Aman Muthrej and Atulan Zaman [3a Comp] wrote solutions to the vhdl labs in Parboiled. • TA’s Jon Eyolfson, Vajih Montaghami, Alireza Mortezaei, Wenzhu Man, and Mohammed Hassan. • TA Wallace Wu developed the vhdl labs. • High school students Brian Engio and Tianyu Guo drew a number of diagrams for this manual, wrote Javadoc comments for the code, and provided helpful comments on the manual. Licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) version 2.5 or greater. http://creativecommons.org/licenses/by-sa/2.5/ca/ http://creativecommons.org/licenses/by-sa/3.0/ Contents 0 Overview 9 Compiler Concepts: call stack, heap 0.1 How the Labs Fit Together . 9 Programming Concepts: version control, push, pull, merge, SSH keys, IDE, 0.2 Learning Progressions . 11 debugger, objects, pointers 0.3 How this project compares to CS241, the text book, etc. 13 0.4 Student work load . 14 0.5 How this course compares to MIT 6.035 .......... 15 0.6 Where do I learn more? .
    [Show full text]
  • Metaprogramming in .NET by Kevin Hazzard Jason Bock
    S AMPLE CHAPTER in .NET Kevin Hazzard Jason Bock FOREWORD BY Rockford Lhotka MANNING Metaprogramming in .NET by Kevin Hazzard Jason Bock Chapter 1 Copyright 2013 Manning Publications brief contents PART 1DEMYSTIFYING METAPROGRAMMING ..............................1 1 ■ Metaprogramming concepts 3 2 ■ Exploring code and metadata with reflection 41 PART 2TECHNIQUES FOR GENERATING CODE ..........................63 3 ■ The Text Template Transformation Toolkit (T4) 65 4 ■ Generating code with the CodeDOM 101 5 ■ Generating code with Reflection.Emit 139 6 ■ Generating code with expressions 171 7 ■ Generating code with IL rewriting 199 PART 3LANGUAGES AND TOOLS ............................................221 8 ■ The Dynamic Language Runtime 223 9 ■ Languages and tools 267 10 ■ Managing the .NET Compiler 287 v Metaprogramming concepts In this chapter ■ Defining metaprogramming ■ Exploring examples of metaprogramming The basic principles of object-oriented programming (OOP) are understood by most software developers these days. For example, you probably understand how encapsulation and implementation-hiding can increase the cohesion of classes. Languages like C# and Visual Basic are excellent for creating so-called coarsely grained types because they expose simple features for grouping and hiding both code and data. You can use cohesive types to raise the abstraction level across a system, which allows for loose coupling to occur. Systems that enjoy loose cou- pling at the top level are much easier to maintain because each subsystem isn’t as dependent on the others as they could be in a poor design. Those benefits are realized at the lower levels, too, typically through lowered complexity and greater reusability of classes. In figure 1.1, which of the two systems depicted would likely be easier to modify? Without knowing what the gray circles represent, most developers would pick the diagram on the right as the better one.
    [Show full text]
  • Increased Efficiency in Finite Element Computations Through Template
    Increased Efficiency In Finite Element Computations Through Template Metaprogramming Karl Rupp Christian Doppler Laboratory for Reliability Issues in Microelectronics at the Institute for Microelectronics, TU Wien Gußhausstraße 27–29/E360, A-1040 Wien, Austria [email protected] Keywords: Template Metaprogramming, Finite Elements, ble selection of the functionality needed for a particular prob- Symbolic Integration, lem at compile time. In order to decouple algorithms acting on a certain geom- Abstract etry, a general way to store and access quantities on domain In the area of scientific computing, abstraction was long said elements is necessary. Our approach works for quantities of to be achievable only in exchange for run time efficiency. arbitrary types and is discussed in Sec. 3. With the rise of template metaprogramming [1] in C++ in The first step towards FEM discretizations is to derive the the 1990s, run time efficiency comparable to hand tuned code weak formulation, which is for second order PDEs obtained could be achieved for isolated operations such as matrix- by multiplication with a test function v, integration over the vector multiplication [2]. In more complex scenarios such whole domain and integration by parts. The generic proce- as large finite element simulation packages, traditional object dure then is to select a suitable basis for a finite dimensional oriented programmingis used for most abstractions, so the re- space of test functions and similarly for trial functions, which sulting code usually suffers from reduced run time efficiency. ultimately leads to a system of linear equations that can be We have applied rigorous template metaprogramming to both solved by either direct or iterative solvers.
    [Show full text]
  • A Code Generation Framework for Actor-Oriented Models with Partial Evaluation
    A Code Generation Framework for Actor-Oriented Models with Partial Evaluation Gang Zhou Man-Kit Leung Edward A. Lee Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2007-29 http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-29.html February 23, 2007 Copyright © 2007, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed 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 to lists, requires prior specific permission. Acknowledgement This paper describes work that is part of the Ptolemy project, which is supported by the National Science Foundation (NSF award number CCR- 00225610), and Chess (the Center for Hybrid and Embedded Software Systems), which receives support from NSF, the State of California Micro Program, and the following companies: Agilent, Bosch, DGIST, General Motors, Hewlett Packard, Microsoft, National Instruments and Toyota. A Code Generation Framework for Actor-Oriented Models with Partial Evaluation Gang Zhou, Man-Kit Leung and Edward A. Lee University of California, Berkeley {zgang, jleung, eal}@eecs.berkeley.edu Abstract. Embedded software requires alternative concurrency formalisms other than threads and mutexes used in traditional programming languages like C. Actor-orient- ed design presents a high level abstraction for composing concurrent components. However, high level abstraction often introduces overhead and results in slower sys- tem.
    [Show full text]
  • Dynamic Software Updates for Parallel High Performance Applications
    CONCURRENCY AND COMPUTATION: PRACTICE AND EXPERIENCE Concurrency Computat.: Pract. Exper. Dynamic Software Updates for Parallel High Performance Applications Dong Kwan Kim, Eli Tilevich∗,†, and Calvin J. Ribbens Center for High-End Computing Systems (CHECS) Dept. of Computer Science, Virginia Tech Blacksburg, VA 24061 SUMMARY Despite using multiple concurrent processors, a typical high performance parallel application is long-running, taking hours, even days to arrive at a solution. To modify a running high performance parallel application, the programmer has to stop the computation, change the code, redeploy, and enqueue the updated version to be scheduled to run, thus wasting not only the programmer’s time, but also expensive computing resources. To address these inefficiencies, this article describes how dynamic software updates can be used to modify a parallel application on the fly, thus saving the programmer’s time and using expensive computing resources more productively. The net effect of updating parallel applications dynamically can reduce the total time that elapses between posing a problem and arriving at a solution, otherwise known as time-to- discovery. To explore the benefits of dynamic updates for high performance applications, this article takes a two-pronged approach. First, we describe our experiences of building and evaluating a system for dynamically updating applications running on a parallel cluster. We then review a large body of literature describing the existing state of the art in dynamic software updates and point out how this research can be applied to high performance applications. Our experimental results indicate that dynamic software updates have the potential to become a powerful tool in reducing time-to-discovery for high performance parallel applications.
    [Show full text]
  • The Csound Plugin Opcode Framework †
    applied sciences Article Supporting an Object-Oriented Approach to Unit Generator Development: The Csound Plugin Opcode Framework † Victor Lazzarini Music Department, Maynooth University, Maynooth W23 X021, Ireland; [email protected]; Tel.: +353-1-708-6936 † This article is a re-written and expanded version of “The Csound Plugin Opcode Framework”, SMC 2017, Espoo, Finland, 5 July 2017. Academic Editor: Stefania Serafin Received: 31 July 2017; Accepted: 18 September 2017; Published: 21 September 2017 Abstract: This article presents a new framework for unit generator development for Csound, supporting a full object-oriented programming approach. It introduces the concept of unit generators and opcodes, and its centrality with regards to music programming languages in general, and Csound in specific. The layout of an opcode from the perspective of the Csound C-language API is presented, with some outline code examples. This is followed by a discussion which places the unit generator within the object-oriented paradigm and the motivation for a full C++ programming support, which is provided by the Csound Plugin Opcode Framework (CPOF). The design of CPOF is then explored in detail, supported by several opcode examples. The article concludes by discussing two key applications of object-orientation and their respective instances in the Csound code base. Keywords: computer music languages; musical signal processing; csound; sound synthesis; object-oriented programming; C++; code re-use; opcodes; unit generators 1. Introduction All modern music programming systems provide means for extending their capabilities [1]. In most cases, this extensibility applies to allowing new unit generators (UGs) to be added to the system.
    [Show full text]
  • Pro Javascript™ Design Patterns
    THE EXPERT’S VOICE® IN WEB DEVELOPMENT Pro JavaScript™ Design Patterns The essentials of object-oriented JavaScript™ programming Ross Harmes and Dustin Diaz www.allitebooks.com www.allitebooks.com Pro JavaScript™ Design Patterns Ross Harmes and Dustin Diaz www.allitebooks.com Pro JavaScript™ Design Patterns Copyright © 2008 by Ross Harmes and Dustin Diaz All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher. ISBN-13 (pbk): 978-1-59059-908-2 ISBN-10 (pbk): 1-59059-908-X ISBN-13 (electronic): 978-1-4302-0495-4 ISBN-10 (electronic): 1-4302-0495-8 Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1 Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems Inc. in the United States and other countries. Apress Inc. is not affiliated with Sun Microsystems Inc., and this book was written without endorsement from Sun Microsystems Inc. Lead Editors: Chris Mills, Tom Welsh Technical Reviewer: Simon Willison Editorial Board: Steve Anglin, Ewan Buckingham, Tony Campbell, Gary Cornell, Jonathan Gennick, Jason
    [Show full text]
  • A Survey of Software Refactoring
    126 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 30, NO. 2, FEBRUARY 2004 A Survey of Software Refactoring Tom Mens, Member, IEEE, and Tom Tourwe´ Abstract—This paper provides an extensive overview of existing research in the field of software refactoring. This research is compared and discussed based on a number of different criteria: the refactoring activities that are supported, the specific techniques and formalisms that are used for supporting these activities, the types of software artifacts that are being refactored, the important issues that need to be taken into account when building refactoring tool support, and the effect of refactoring on the software process. A running example is used throughout the paper to explain and illustrate the main concepts. Index Terms—Coding tools and techniques, programming environments/construction tools, restructuring, reverse engineering, and reengineering. æ 1INTRODUCTION N intrinsic property of software in a real-world does not alter the external behavior of the code, yet improves its Aenvironment is its need to evolve. As the software is internal structure” [7]. The key idea here is to redistribute enhanced, modified, and adapted to new requirements, the classes, variables, and methods across the class hierarchy in code becomes more complex and drifts away from its order to facilitate future adaptations and extensions. original design, thereby lowering the quality of the soft- In the context of software evolution, restructuring and ware. Because of this, the major part of the total software refactoring are used to improve the quality of the software development cost is devoted to software maintenance [1], (e.g., extensibility, modularity, reusability, complexity, [2], [3].
    [Show full text]
  • Design Patterns Pro Javascript
    CYAN YELLOW MAGENTA BLACK PANTONE 123 C BOOKS FOR PROFESSIONALS BY PROFESSIONALS® THE EXPERT’S VOICE® IN WEB DEVELOPMENT Companion eBook Available ™ Pro JavaScript Design Patterns Pro JavaScript Dear Reader, Web programming is becoming more complex and collaborative each day. A new JavaScript™ library is born each week, and we are getting closer to the time when web applications can seamlessly replace those found on our desktops. It is no longer possible to design the behavior of your sites haphazardly without thinking about long-term software maintainability. The JavaScript language has matured. We have reached a point where soft- Pro ware development techniques once considered useful only in languages such as Java and C++ are being applied to web programming. Therefore, we felt the ™ time has come for a book that explores object-oriented design principles and applies them to the JavaScript language. The techniques needed to implement patterns like factory, singleton, observer, composite, and facade in JavaScript are easily understood, but they have not previously been discussed in depth in a single book. We wanted to show programmers that JavaScript contains features JavaScript on par with other high-level languages and is an object-oriented programming language in its own right. In fact, we wrote the book that we ourselves have always ™ wanted to read. Design Patterns In this book, we will teach you about commonly used software patterns for designing the code that drives your websites and applications. You will learn object-oriented JavaScript programming, starting with routine tasks and pro- Design Patterns gressing to advanced techniques and patterns.
    [Show full text]
  • A Code Generation Framework for Actor-Oriented Models with Partial Evaluation
    A Code Generation Framework for Actor-Oriented Models with Partial Evaluation Gang Zhou, Man-Kit Leung, and Edward A. Lee University of California, Berkeley {zgang,jleung,eal}@eecs.berkeley.edu Abstract. Embedded software requires concurrency formalisms other than threads and mutexes used in traditional programming languages like C. Actor-oriented design presents a high level abstraction for com- posing concurrent components. However, high level abstraction often in- troduces overhead and results in slower system. We address the problem of generating efficient implementation for the systems with such a high level description. We use partial evaluation as an optimized compilation technique for actor-oriented models. We use a helper-based mechanism, which results in flexible and extensible code generation framework. The end result is that the benefit offered by high level abstraction comes with (almost) no performance penalty. The code generation framework has been released in open source form as part of Ptolemy II 6.0.1. 1 Introduction Embedded software has been traditionally written with assembly language to maximize efficiency and predictability. Programming languages like C are used to improve productivity and portability. These imperative programming lan- guages essentially abstract how a Von Neumann computer operates in a sequen- tial manner. They are good matches for general-purpose software applications, which are essentially a series of data transformations. However, in the embedded world, the computing system constantly engages the physical system. Thus the physical system becomes an integral part of the design and the software must operate concurrently with the physical system. The basic techniques for doing concurrent programming on top of traditional programming languages like C use threads, complemented with synchronization mechanisms like semaphores and mutual exclusion locks.
    [Show full text]
  • Programming Language Abstractions for Mobile Code
    PROGRAMMING LANGUAGE ABSTRACTIONS FOR MOBILE CODE THÈSE NO 4515 (2009) PRÉSENTÉE LE 23 OCTOBRE 2009 À LA FACULTÉ INFORMATIQUE ET COMMUNICATIONS LABORATOIRE DE MÉTHODES DE PROGRAMMATION 1 SECTION D'INFORMATIQUE ÉCOLE POLYTECHNIQUE FÉDÉRALE DE LAUSANNE POUR L'OBTENTION DU GRADE DE DOCTEUR ÈS SCIENCES PAR Stéphane MICHELOUD acceptée sur proposition du jury: Prof. A. Wegmann, président du jury Prof. M. Odersky , directeur de thèse Prof. M. Merro, rapporteur Prof. C. Petitpierre, rapporteur Dr J. H. Spring, rapporteur Lausanne, EPFL 2009 This document was processed using TEX Live 2007 for Linux Schemas were created using Dia 0.95 for Linux Screenshots were captured using ImageMagick 6.2.4 for Linux to Inês and David iv Contents Abstract xx Acknowledgments xxiv 1 Introduction1 1.1 Motivation.............................2 1.2 Scope................................8 1.3 Background............................8 1.3.1 The Scala Language...................8 1.3.2 The Java Platform.................... 10 1.4 Contributions........................... 11 1.5 Outline............................... 12 2 Multi-paradigm Programming 13 2.1 Functional Programming.................... 14 2.1.1 Higher-Order Functions................. 14 2.1.2 Lexical Closures..................... 26 2.2 Distributed Programming.................... 30 2.2.1 Historical Survey..................... 30 2.2.2 Remote Procedure Calls................. 31 2.2.3 Remote Evaluation.................... 33 2.2.4 OMG CORBA....................... 36 2.2.5 Java RMI.......................... 37 2.2.6 .NET Remoting...................... 38 2.3 Distributed Programming in Java............... 40 2.3.1 Distributed Objects.................... 40 2.3.2 Distributed Exception Handling............ 41 2.3.3 Distributed Garbage Collection............. 41 2.4 Discussion............................. 43 vi CONTENTS 3 Code Mobility 45 3.1 Forms of Code Mobility....................
    [Show full text]
  • Programming Language Principles and Paradigms Release 0.3-Alpha
    Programming Language Principles and Paradigms Release 0.3-alpha Amir Kamil Feb 22, 2021 CONTENTS I Foundations1 1 Introduction 3 2 Basic Python 5 2.1 Variables.................................................5 2.2 Basic Data Structures..........................................6 2.3 Compound Statements..........................................8 2.4 Function Definitions...........................................8 2.5 Class Definitions.............................................9 2.6 Modules................................................. 10 2.7 Executing a Module........................................... 10 3 Basic Elements 12 3.1 Levels of Description........................................... 12 3.2 Entities, Objects, and Variables..................................... 14 3.3 L-Values and R-Values.......................................... 14 3.4 Expressions................................................ 15 3.5 Statements................................................ 16 4 Names and Environments 17 4.1 Blocks.................................................. 18 4.2 Name Lookup.............................................. 19 4.3 Nested Inline Blocks........................................... 20 4.4 Scope in Functions............................................ 21 4.5 Static Scope............................................... 22 4.6 Dynamic Scope.............................................. 24 4.7 Point of Declaration or Definition.................................... 25 4.8 Implementation Strategies.......................................
    [Show full text]