DOCSLIB.ORG

Scheduling Deterministic Parallel Programs

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Scheduling Deterministic Parallel Programs Scheduling Deterministic Parallel Programs Daniel John Spoonhower CMU-CS-09-126 May 18, 2009 School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Thesis Committee: Guy E. Blelloch (co-chair) Phillip B. Gibbons Robert Harper (co-chair) Simon L. Peyton Jones (Microsoft Research) Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy. Copyright c 2009 Daniel John Spoonhower This research was sponsored by Microsoft, Intel, and IBM. 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 any sponsoring institution, the U.S. government or any other entity. Keywords: parallelism, scheduling, cost semantics Abstract Deterministic parallel programs yield the same results regardless of how parallel tasks are interleaved or assigned to processors. This drastically simplifies reason- ing about the correctness of these programs. However, the performance of parallel programs still depends upon this assignment of tasks, as determined by a part of the language implementation called the scheduling policy. In this thesis, I define a novel cost semantics for a parallel language that en- ables programmers to reason formally about different scheduling policies. This cost semantics forms a basis for a suite of prototype profiling tools. These tools allow programmers to simulate and visualize program execution under different schedul- ing policies and understand how the choice of policy affects application memory use. My cost semantics also provides a specification for implementations of the lan- guage. As an example of such an implementation, I have extended MLton, a com- piler and runtime system for Standard ML, with support for parallelism and imple- mented several different scheduling policies. Using my cost semantics and profiler, I found a memory leak caused by a bug in one of the existing optimizations in MLton. In addition to memory use, this cost semantics precisely captures when a par- allel schedule deviates from the uni-processor execution of a given program. The number of deviations acts as a important conceptual tool in reasoning about concrete measures of performance. I use this metric to derive new bounds on the overhead of existing work stealing implementations of parallel futures and to suggest more efficient alternatives. This work represents an important step in understanding how to develop pro- grams and programming languages for multi-core and multi-processor architectures. In particular, a cost semantics provides an abstraction that helps to ensure adequate performance without sacrificing the ability to reason about programs at a high level. iv to Copic vi Acknowledgments When I arrived at Carnegie Mellon, I expected to find bright, motivated people working on exciting problems. I found not only that but also a vibrant community of students, especially among the students of the Principles of Programming group. Many of these students became not only my colleagues but also my friends. Their passion and enthusiasm for programming languages, logic, and computer science escapes from campus and into homes, restaurants, and bars. In particular, I would like to thank those senior students who helped to establish this community within our group, especially Kevin Watkins, Leaf Peterson, Derek Dreyer, and Tom Mur- phy VII, as well as those who continue to maintain it, especially Jason Reed, Dan Licata, William Lovas, Rob Simmons, and the other members of the ConCert Read- ing Group. It have been extremely gratifying to have participated in this culture and to see that culture persist beyond my time at CMU. I would like to thank the MLton developers, especially Matthew Fluet, for pro- viding the foundation upon which I did much of my implementation and for provid- ing technical support. Pittsburgh has been a great place to live while pursuing my graduate studies. This is due in a large part to the great people I have met here. This includes many fantastic people at CMU, including Rose Hoberman, Katrina Ligett, Adam Goode, Chris Twigg, Tiankai Tu, and those mentioned above; the D’s regulars, especially Heather Hendrickson, Stephen Hancock, and Laura Marinelli; and the Alder Street crowd, especially Ryan Kelly and Jessica Nelson who provided a place to stay and a home while I was traveling frequently. My advisers, Bob Harper and Guy Blelloch, and Phil Gibbons, who became a third adviser, were (of course) instrumental in my success as a graduate student. I am deeply grateful for their unflinching support and confidence in me. I would also like to acknowledge the role of Dan Huttenlocher, who has been a friend and mentor since before I started graduate school and who has helped me to make many important decisions along the way. Finally, I would also like to thank my parents, Tom and Sue, and the rest of my family for always encouraging me to do my best and Kathy Copic for never accepting less than that. viii Preface Like all endeavors of human understanding, the goals of computer science are to generalize our experience and to build models of the world around us. In the case of computer science, these models describe computers, programs, algorithms, and other means of processing information. The purpose of these models is to enable us to understand more about existing phenomena and artifacts, including both those that are purely conceptual and those that are physical in nature. These models also enable us to discover and develop new ways of processing information. As in other areas of study, these models are justified by their capacity to make predictions about existing phenomena or to connect ideas that were previously considered unrelated or disparate. As a study of information, computer science is also concerned with these models themselves and with the means used to justify them. In a sense, abstraction, one of the most important conceptual tools of computer science, is the practice of divid- ing information about a system into that which will help us to learn more about its behavior and that which impedes our understanding. Despite the unifying goal of computer science to better understand how informa- tion is processed, work in our field is often divided into two broad but disjoint cat- egories: theory and systems. However, these need not be competing sub-fields but instead, complementary approaches for evaluating models about information and in- formation processing systems. In this thesis, I develop new models about languages for parallel programming. In addition, I use approaches based on both theory and practice to evaluate these models. My hope is that these models will serve to help future language implementers understand how to efficiently exploit parallel archi- tectures. x Contents 1 Introduction 1 1.1 Parallelism . .1 1.2 Scheduling . .3 1.3 Cost Semantics . .4 1.4 Overview . .6 1.5 Contributions . .8 2 Cost Semantics 9 2.1 Example: Matrix Multiplication . .9 2.2 Syntax . 12 2.3 Graphs . 13 2.4 Semantics . 14 2.5 Schedules and Deviations . 17 2.5.1 Sequential Schedules . 18 2.5.2 Deviations . 19 2.6 Memory Use . 20 2.7 Sequential Extensions . 26 2.8 Alternative Rules . 27 2.9 Summary . 28 2.10 Related Work . 28 3 Online Scheduling 31 3.1 Non-Deterministic Scheduling . 33 3.1.1 Confluence . 33 3.1.2 Soundness . 37 3.1.3 Completeness . 38 3.2 Greedy Scheduling . 42 3.3 Depth-First Scheduling . 45 3.3.1 Semantics . 46 3.3.2 Determinacy . 47 3.3.3 Progress . 48 3.3.4 Soundness . 48 3.3.5 Completeness . 49 3.3.6 Greedy Semantics . 51 xi 3.4 Breadth-First Scheduling . 51 3.4.1 Semantics . 52 3.4.2 Soundness . 56 3.5 Work-Stealing Scheduling . 57 3.6 Summary . 60 3.7 Related Work . 60 4 Semantic Profiling 61 4.1 Simulation . 62 4.1.1 Example: Matrix Multiplication . 65 4.2 Visualization . 66 4.2.1 Distilling Graphs . 67 4.2.2 GraphViz . 68 4.2.3 Example: Matrix Multiplication . 69 4.2.4 Example: Quickhull . 71 4.3 Summary . 73 4.4 Related Work . 73 5 Vector Parallelism 75 5.1 Example: Matrix Multiplication . 76 5.2 Syntax . 78 5.3 Semantics . 79 5.3.1 Cost Semantics . 81 5.3.2 Implementation Semantics . 81 5.4 Flattening . 82 5.5 Labeling . 85 5.6 Summary . 90 5.7 Related Work . 90 6 Parallel Futures 91 6.1 Syntax and Semantics . 94 6.2 Work Stealing . 96 6.2.1 Cilk . 96 6.2.2 Bounding Steals . 97 6.2.3 Beyond Nested Parallelism . 98 6.3 Deviations . 99 6.3.1 Deviations Resulting From Futures . 100 6.3.2 Performance Bounds . 101 6.4 Bounds on Deviations . 104 6.4.1 Upper Bound . 104 6.4.2 Lower Bound . 107 6.5 Alternative Implementations . 109 6.6 Speculation . 111 6.6.1 Glasgow Parallel Haskell . 111 xii 6.6.2 Cost Semantics . 113 6.7 Summary . ..
Load more

Recommended publications
  • How to Design Co-Programs
    JFP, 15 pages, 2021. c Cambridge University Press 2021 1 doi:10.1017/xxxxx EDUCATIONMATTERS How to Design Co-Programs JEREMY GIBBONS Department of Computer Science, University of Oxford e-mail: [email protected] Abstract The observation that program structure follows data structure is a key lesson in introductory pro- gramming: good hints for possible program designs can be found by considering the structure of the data concerned. In particular, this lesson is a core message of the influential textbook “How to Design Programs” by Felleisen, Findler, Flatt, and Krishnamurthi. However, that book discusses using only the structure of input data for guiding program design, typically leading towards structurally recur- sive programs. We argue that novice programmers should also be taught to consider the structure of output data, leading them also towards structurally corecursive programs. 1 Introduction Where do programs come from? This mystery can be an obstacle to novice programmers, who can become overwhelmed by the design choices presented by a blank sheet of paper, or an empty editor window— where does one start? A good place to start, we tell them, is by analyzing the structure of the data that the program is to consume. For example, if the program h is to process a list of values, one may start by analyzing the structure of that list. Either the list is empty ([]), or it is non-empty (a : x) with a head (a) and a tail (x). This provides a candidate program structure: h [ ] = ::: h (a : x) = ::: a ::: x ::: where for the empty list some result must simply be chosen, and for a non-empty list the result depends on the head a and tail x.
    [Show full text]
  • Final Shift for Call/Cc: Direct Implementation of Shift and Reset
    Final Shift for Call/cc: Direct Implementation of Shift and Reset Martin Gasbichler Michael Sperber Universitat¨ Tubingen¨ fgasbichl,[email protected] Abstract JxKρ = λk:(k (ρ x)) 0 0 We present a direct implementation of the shift and reset con- Jλx:MKρ = λk:k (λv:λk :(JMK)(ρ[x 7! v]) k ) trol operators in the Scheme 48 system. The new implementation JE1 E2Kρ = λk:JE1Kρ (λ f :JE2Kρ (λa: f a k) improves upon the traditional technique of simulating shift and reset via call/cc. Typical applications of these operators exhibit Figure 1. Continuation semantics space savings and a significant overall performance gain. Our tech- nique is based upon the popular incremental stack/heap strategy for representing continuations. We present implementation details as well as some benchmark measurements for typical applications. this transformation has a direct counterpart as a semantic specifica- tion of the λ calculus; Figure 1 shows such a semantic specification for the bare λ calculus: each ρ is an environment mapping variables Categories and Subject Descriptors to values, and each k is a continuation—a function from values to values. An abstraction denotes a function from an environment to a D.3.3 [Programming Languages]: Language Constructs and Fea- function accepting an argument and a continuation. tures—Control structures In the context of the semantics, the rule for call/cc is this: General Terms Jcall=cc EKρ = λk:JEKρ (λ f : f (λv:λk0:k v) k) Languages, Performance Call=cc E evaluates E and calls the result f ; it then applies f to an Keywords escape function which discards the continuation k0 passed to it and replaces it by the continuation k of the call=cc expression.
    [Show full text]
  • Practical Ruby Projects: Practical Ruby Projects Ideas for the Eclectic Programmer
    CYAN YELLOW MAGENTA BLACK PANTONE 123 C BOOKS FOR PROFESSIONALS BY PROFESSIONALS® THE EXPERT’S VOICE® IN OPEN SOURCE Companion eBook Available Practical Ruby Projects: Projects Ruby Practical Ideas for the Eclectic Programmer Dear Reader, You’ve learned the basics of Ruby, and you’re ready to move on to the next level— trying out advanced techniques, mastering best practices, and exploring Ruby’s full potential. With this book you’ll learn by experience while you tackle an exciting series of varied but always practical programming projects. What is an eclectic programmer, you ask? He or she is an inquisitive thinker Practical who likes to play around with new concepts, a person who is project-oriented and enjoys coding, a person who doesn’t mind some technical depth folded in with creative excursions, and a person who is always looking for fresh ideas. This book is a little different from other computer books. It is meant to be entertaining, exciting, and intellectually challenging. Inside you’ll find a collec- tion of diverse projects, ranging from the creative to the practical, written as a nod to all the great Rubyists I’ve been privileged to know. Each chapter dives into Ruby Projects new topics and approaches meant to exercise your programming muscles. You’ll start by building a cross-platform music environment, progress to drawing animations using scalable vector graphics, and then move on to prac- tical problem solving using simulation. In addition, you’ll implement your own turn-based strategy game and build a Mac-native RubyCocoa interface to it.
    [Show full text]
  • The Racket Manifesto∗
    The Racket Manifesto∗ Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, Shriram Krishnamurthi Eli Barzilay, Jay McCarthy, Sam Tobin-Hochstadt Abstract The creation of a programming language calls for guiding principles that point the developers to goals. This article spells out the three basic principles behind the 20-year development of Racket. First, programming is about stating and solving problems, and this activity normally takes place in a context with its own language of discourse; good programmers ought to for- mulate this language as a programming language. Hence, Racket is a programming language for creating new programming languages. Second, by following this language-oriented approach to programming, systems become multi-lingual collections of interconnected components. Each language and component must be able to protect its specific invariants. In support, Racket offers protection mechanisms to implement a full language spectrum, from C-level bit manipulation to soundly typed extensions. Third, because Racket considers programming as problem solving in the correct language, Racket also turns extra-linguistic mechanisms into linguistic constructs, especially mechanisms for managing resources and projects. The paper explains these principles and how Racket lives up to them, presents the evaluation framework behind the design process, and concludes with a sketch of Racket’s imperfections and opportunities for future improvements. 1998 ACM Subject Classification D.3.3 Language Constructs and Features Keywords and phrases design
    [Show full text]
  • Matthias Felleisen, Plt, Nuprl the Beginning (1992/95)
    DEVELOPING DEVELOPERS MATTHIAS FELLEISEN, PLT, NUPRL THE BEGINNING (1992/95) C++ SiCP CS I C, AP, high schools Pascal, Ratfor, the “better math” Fortran “computational” physics economics “come alive” THE BEGINNING (1992/95) ‣ Robby Findler Dist Sys Dev ‣ Kathi Fisler Sw Dev ~ just ‣ Matthew Flatt before students ‣ Shriram Krishnamurthi C++ study Sw Eng SiCP C++ ‣ Emmanuel Schanzer CS II: if CS I is about “Scheme”, what roles CS I does CS it serve? C, TeachScheme! Pascal, Ratfor, ‣ Robert Cartwright (Rice) Fortran Program By Design ‣ Robby Findler Bootstrap ‣ Peter Druschel (MPI-SWS) ‣ Mike Ernst (UW) THE BEGINNING (1992/95) Dist Sys Dev Sw Dev ~ just before students C++ study Sw Eng SiCP C++ CS II: if CS I is about “Scheme”, what roles CS I does CS it serve? C, Pascal, Ratfor, Fortran WHERE I AM TODAY TODAY’S WORLD @ NU CCIS: TECHNICAL SKILLS & COMMUNICATION SKILLS Sw Dev CO OP communication technical skills: skills: conversing systematic about code creation of code OOD CS II LiCS CS I TODAY’S WORLD @ NU CCIS: TECHNICAL SKILLS & COMMUNICATION SKILLS pair programming, scale problem panel/peer review, Sw Dev complexity and memos on code size; consolidate 6-month job-like setting, code in CO OP “the real world” pair programming, scale it up in Java, code review logic in interface OOD proving theorems about systematic design, CS II LiCS (functional) code, dual to typed & OOPL (Java) systematic design pair programming, pair programming code review CS I functional pair programming programming for systematic design TODAY’S WORLD @ NU CCIS: TECHNICAL
    [Show full text]
  • Category D: Published Publications on Lisp/Common Lisp (Duplication
    Category D: Published Publications on Lisp/Common Lisp (duplication checked) Category D-1) Lisp and Common Lisp Books ANSI Common Lisp Paul Graham Prentice Hall 1996 A Programmer’s Guide to Common Lisp Deborah G.Tatar Digital Press 1987 Common Lisp The Reference Franz Inc. Addison-Wesley 1988 Common Lisp Guy L.Steele Jr. (in Japanese) Tr. by Eiichi Goto and Masayuki Ida Kyoritsu Pub. 1984 Common Lisp Second Edition Guy L.Steele Jr. (in Japanese) Tr.by Masayuki Ida, Kyoritsu Pub. 1990 Lisp 3rd Edition Patrick Henry Winston/Berthold Klaus Paul Horn Addison-Wesley 1989 Lisp Patrick Henry Winston/Berthold Klaus Paul Horn (in Japanese) Baihuukan1982 Lisp(1) Third Edition Patrick Henry Winston/Berthold Klaus Paul Horn(in Japanese) Baihuukan1991 Lisp(2) Third Edition Patrick Henry Winston/Berthold Klaus Paul Horn(in Japanese) Baihuukan1991 Lisp Style & Design Molly M.Miller/Eric Benson Digital Press 1990 The Common Lisp Companion Timothy D.Koschmann John Wiley & Sons 1990 The Little LISPer Trade Edition Daniel P.Friedman/Matthias Felleisen MIT Press 1987 The T Programming Language-A Dialect of Lisp- Stephen Slade Prentice Hall 1987 Common Lisp Interface Manager, Release 1 Specification, December 12, 1990 Category D-2) Related Languages and Documents BCPL – the language and its compiler, by M. Richards and C Whitby-Strevens, Cambridge U Press, 1980 B Reference Manual, U Waterloo, 1977 Scheme: Past, Present and Future, by Guy Steele and Masayuki Ida, CSRL Technical Report 95-009, Aoyama Gakuin University, 1995 Programming Languages, ed.by F. Genuys, NATO advanced study institute, Academic Press, 1968 (including “Co-operating Sequential Processes” by E.W.Dijkstra and others) Some Philosophical Problems from the Standpoint of Artificial Intelligence, by J.
    [Show full text]
  • Learning to Program in a Constructionist Way Mattia Monga, Michael Lodi, Dario Malchiodi, Anna Morpurgo, Bernadette Spieler
    Learning to program in a constructionist way Mattia Monga, Michael Lodi, Dario Malchiodi, Anna Morpurgo, Bernadette Spieler To cite this version: Mattia Monga, Michael Lodi, Dario Malchiodi, Anna Morpurgo, Bernadette Spieler. Learning to program in a constructionist way. Proceedings of Constructionism 2018, Aug 2018, Vilnius, Lithuania. hal-01913065 HAL Id: hal-01913065 https://hal.inria.fr/hal-01913065 Submitted on 6 Nov 2018 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Learning to program in a constructionist way Constructionism Working Group 6 Michael Lodi∗ Dario Malchiodi Bernadette Spieler Alma Mater Studiorum - Mattia Monga Technische Universität Graz Università di Bologna Anna Morpurgo Austria Italy [email protected] [email protected] [email protected] [email protected] [email protected] Università degli Studi di Milano Italy ABSTRACT skills, as is recognizing how a relatively low number of abstract Although programming is often seen as a key element of construc- patterns can be applied to a potentially infinite spectrum of specific tionist approaches, the research on learning to program through situations.Programming languages and environments can either a constructionist strategy is somewhat limited, mostly focusing help or distract novices, thus the choice is not neutral and their on how to bring the abstract and formal nature of programming characteristics should be analyzed carefully to foster a good learn- languages into “concrete” or even tangible objects, graspable even ing context.
    [Show full text]
  • Venue Medley for the Novice
    Venue Medley for the Novice Release 2.0 February, 1992 Address comments to: Venue User Documentation 1549 Industrial Road San Carlos, CA 94070 415-508-9672 Medley for the Novice Release 2.0 February 1992 Copyright 1992 by Venue. All rights reserved. Medley is a trademark of Venue. Xerox is a registered trademark and InterPress is a trademark of Xerox Corporation. UNIX is a registered trademark of UNIX System Laboratories. PostScript is a registered trademark of Adobe Systems Inc. Copyright protection includes material generated from the software programs displayed on the screen, such as icons, screen display looks, and the like. The information in this document is subject to change without notice and should not be construed as a commitment by Venue. While every effort has been made to ensure the accuracy of this document, Venue assumes no responsibility for any errors that may appear. Text was written and produced with Venue text formatting tools; Xerox printers were used to produce text masters. The typeface is Classic. PREFACE It was dawn and the local told him it was down the road a piece, left at the first fishing bridge in the country, right at the appletree stump, and onto the dirt road just before the hill. At midnight he knew he was lost. -Anonymous Welcome to the Medley Lisp Development Environment, a collection of powerful tools for assisting you in programming in Lisp, developing sophisticated user interfaces, and creating prototypes of your ideas in a quick and easy manner. Unfortunately, along with the power comes mind-numbing complexity. The Medley documentation set describes all the tools in detail, but it would be unreasonable for us to expect a new user to wade through all of it, so this primer is intended as an introduction, to give you a taste of some of the features.
    [Show full text]
  • Matthias FELLEISEN, Daniel P. FRIEDMAN, El:Gene KOHLBECKER and Bruce DUBA “The Lambda Calculus Is a Type-Free Theory About
    Theoretical Computer Science 52 (1987) 205-237 205 North-Holland Matthias FELLEISEN, Daniel P. FRIEDMAN, El:gene KOHLBECKER and Bruce DUBA Computer Science Department, Lindley Hall 101, Indiana Vniuersity, Bloomington, IN 47405, U.S.A. Communicated by R. Milner Received April 1986 Revised February 1987 Abstract. Sequential control operators like J and call/cc are often found in implementations of the h-calculus as a programming language. Their semantics is always defined by the evaluation function of an abstract machine. We show that, given such a machine semantics, one can derive an algebraic extension of the AU-calculus. The extended calculus satisfies the diamond property and contains a Church-Rosser subcalculus. This underscores that the interpretation of control operators is to a certain degree independent of a specific evaluation strategy. We also prove a standardization theorem and use it to investigate the correspondence between the machine and the calculus. Together, the calculus and the rewriting machine form a syntactic theory of control, which provides a natural basis for reasoning about programs with nonfunctional control operators. 1. Deficiencies of the A-calculus as a programming language “The lambda calculus is a type-free theory about functions as rules, rather than graphs. ‘Functions as rules’ . refers to the process of going from argument to value, . .” [I, p. 31 No other words can better express why computer scientists have been intrigued with the A-calculus. The rule character of function evaluation comes close to a programmer’s operational understanding of computer programs and, at the same time, the calculus provides an algebraic framework for reasoning about functions.
    [Show full text]
  • Contracts for First-Class Classes
    Contracts for First-Class Classes T. Stephen Strickland Matthias Felleisen PLT @ Northeastern University fsstrickl,[email protected] Abstract from a superclass and combines it with traits via glue code First-class classes add expressive power to class-based that manages name clashes or other small mismatches. Both object-oriented languages. Most importantly, programmers Scala [40] and Fortress [2] support traits. can abstract over common scenarios with first-class classes. Smalltalk [20], OCaml [32, 43], and Racket [18], for- When it comes to behavioral software contracts, however, merly known as PLT Scheme, take the final step and turn first-class classes pose significant challenges. In this paper, classes into first-class values. In such a world, the evaluation we present the first contract system for a programming lan- of an expression may produce a class. Methods and functions guage with first-class classes. The design has been imple- may consume and produce classes. Objects may store classes mented for Racket, which supports first-class classes and in fields. And most importantly, the super-class designator in which implements mixins and traits as syntactic sugar. We a class is just an expression, meaning the super-class is com- expect that our experience also applies to languages with puted at run-time. Equipped with this power, a programmer native mixins and/or traits. can add mixins and traits as “syntactic sugar” [16] but even better, a programmer can explore entirely new ways of orga- Categories and Subject Descriptors D[2]: 3 Object- nizing class-based programs. oriented programming; D [2]: 4 Programming by contract Racket, like Eiffel [38] and many other object-oriented languages [5, 8, 22, 24, 26, 27, 29, 34, 38, 42], also comes General Terms Reliability with a contract system.
    [Show full text]
  • Web Programming with Continuations
    Web Programming with Continuations William E. Byrd∗ November 20, 2002 Contents 1 The Big Idea 2 2 The Problem 2 3 Using Continuations to Add State to the Web 3 4 Issues to Consider 3 4.1 Saving the continuation . 3 4.1.1 Save it on the Server . 3 4.1.2 Save it on the Client . 4 4.1.3 Hybrid Approach . 4 4.2 Simulating Continuations in Other Languages . 4 5 Advantages 5 6 Limitations 5 7 Some Systems in Use 6 8 Open Problems 6 9 A Modest Proposal 7 ∗Author’s e-mail address: emacs [email protected] 1 1 THE BIG IDEA 2 10 Further Reading 7 10.1 Continuations . 7 10.2 Web Programming with Continuations . 8 1 The Big Idea Scheme supports first-class continuations, which can be resumed an arbitrary number of times. These continuations can be used to make HTTP behave like a stateful protocol, and can even eliminate the need for session time-outs. Although continuation-based approaches to Web programming looks promis- ing, several important issues related to the use of continuations still need to be addressed before these techniques will gain commercial acceptance. 2 The Problem Since HTTP is a stateless protocol, Web applications themselves must main- tain conversational state with each client. The usual approach is to break the application into a number of small pieces (JSP’s, Java Servlets, CGI scripts, etc.), each of which is capable of handling a small number of requests. This approach suffers from several problems: • legacy applications not written in this style are difficult to adapt to the Web • breaking the application into pieces may make
    [Show full text]
  • From Principles to Practice with Class in the First Year
    From Principles to Practice with Class in the First Year Sam Tobin-Hochstadt David Van Horn Northeastern University Boston, Massachusetts, USA fsamth,[email protected] We propose a bridge between functional and object-oriented programming in the first-year curricu- lum. Traditionally, curricula that begin with functional programming transition to a professional, usually object-oriented, language in the second course. This transition poses obstacles for students, and often results in confusing the details of development environments, syntax, and libraries with the fundamentals of OO programming that the course should focus on. Instead, we propose to begin the second course with a sequence of custom teaching languages which minimize the transition from the first course, and allow students to focus on core ideas. After working through the sequence of pedagogical languages, we then transition to Java, at which point students have a strong command of the basic principles. We have 3 years of experience with this course, with notable success. 1 Introduction Many universities and colleges aim to teach their students proficiency in an industrial object-oriented programming language by the end of the students’ first year. The most common approach to achieve this aim is to teach an industrial language in the first course, often Java, starting on the first day. Other curricula take a more indirect route by teaching functional programming in the first semester, followed by a second semester in Java. The latter approach is an improvement over the first, as pointed out by numerous observers [9, 23, 7, 22], but both suffer serious flaws. As an example, Northeastern University teaches introductory programming in the first semester using How to Design Programs [8], followed by object-oriented programming using How to Design Classes [11] in the second semester.
    [Show full text]