DOCSLIB.ORG

An Efficient Implementation of Guard-Based Synchronization for an Object-Oriented Programming Language an Efficient Implementation of Guard-Based

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
An Efficient Implementation of Guard-Based Synchronization for an Object-Oriented Programming Language an Efficient Implementation of Guard-Based AN EFFICIENT IMPLEMENTATION OF GUARD-BASED SYNCHRONIZATION FOR AN OBJECT-ORIENTED PROGRAMMING LANGUAGE AN EFFICIENT IMPLEMENTATION OF GUARD-BASED SYNCHRONIZATION FOR AN OBJECT-ORIENTED PROGRAMMING LANGUAGE By SHUCAI YAO, M.Sc., B.Sc. A Thesis Submitted to the Department of Computing and Software and the School of Graduate Studies of McMaster University in Partial Fulfilment of the Requirements for the Degree of Doctor of Philosophy McMaster University c Copyright by Shucai Yao, July 2020 Doctor of Philosophy (2020) McMaster University (Computing and Software) Hamilton, Ontario, Canada TITLE: An Efficient Implementation of Guard-Based Synchro- nization for an Object-Oriented Programming Language AUTHOR: Shucai Yao M.Sc., (Computer Science) University of Science and Technology Beijing B.Sc., (Computer Science) University of Science and Technology Beijing SUPERVISOR: Dr. Emil Sekerinski, Dr. William M. Farmer NUMBER OF PAGES: xvii,167 ii To my beloved family Abstract Object-oriented programming has had a significant impact on software development because it provides programmers with a clear structure of a large system. It encap- sulates data and operations into objects, groups objects into classes and dynamically binds operations to program code. With the emergence of multi-core processors, application developers have to explore concurrent programming to take full advan- tage of multi-core technology. However, when it comes to concurrent programming, object-oriented programming remains elusive as a useful programming tool. Most object-oriented programming languages do have some extensions for con- currency, but concurrency is implemented independently of objects: for example, concurrency in Java is managed separately with the Thread object. We employ a programming model called Lime that combines action systems tightly with object- oriented programming and implements concurrency by extending classes with actions and guarded methods. This provides programmers with a unified and straightforward design view for a concurrent object-oriented program. In this work, using coroutines with guarded methods and actions is proposed as a means of implementing the concurrency extension for objects. Mapping objects to coroutines can result in stack overflow as the number of objects increases. A dy- namically segmented stack mechanism, which does not introduce runtime overhead, is implemented to support large-scale concurrency. Since Lime allows guarded meth- ods and actions to \get stuck," a new user-level cooperative scheduler, and a fast coroutine context switch mechanism are implemented to improve the performance. Compared with the traditional segmented stack mechanisms, the new dynamically segmented stack mechanism gets equal performance for more common scenarios. Be- sides, it outperforms the contemporary stack mechanisms for deep recursion scenarios. Above all, Lime does not only provide the programmers with a unified and straight- forward object-oriented programming model for concurrency, but also accomplishes a better performance than concurrent programming languages such as Erlang and Go, in fine-grained, highly concurrent benchmarks. iii Acknowledgements First and foremost, I would like to express my gratitude to my academic supervisor Dr. Emil Sekerinski for his unwavering support, invaluable guidance, and continuous encouragement throughout the development and advancement of my research studies. Secondly, I would like to express great appreciation to my co-supervisor, Dr. William M. Farmer, for his excellent comments and suggestions on my thesis and a careful review of the thesis. My special thanks go to the other members of my supervisory committee: Dr. Wolfram Kahl and Dr. Frantisek (Franya) Franek, for excellent comments and sug- gestions on supervisory committee meetings and a careful review of the thesis. I also appreciate the help and moral support from all of the other individuals whom I have interacted with throughout my graduate studies. Furthermore, I want to extend my sincere thanks to the China Scholarship Council, Global Water Futures and McMaster University graduate scholarship, which have provided financial support during my doctoral studies. Last, but certainly not least, I would like to thank my dear family and my fellow graduate students, Dr. Ronald Eden Burton, Dr. Bojan Nokovic and Dr. Tian Zhang for their constructive feedback in our group meetings. iv Contents Abstract iii Acknowledgements iv Declaration of Academic Achievement xvii 1 Introduction2 1.1 Processors.................................2 1.1.1 Uniprocessors...........................2 1.1.2 Multicore Processors.......................6 1.1.3 Microprocessor Performance and Trends............7 1.2 Object-Oriented Programming Languages...............7 1.2.1 Sequential Programming.....................8 1.2.2 Concurrent Programming....................9 1.3 Problems This Thesis Addresses..................... 10 1.4 Contributions............................... 11 1.5 Structure of the Thesis.......................... 11 2 Concurrency Models 12 2.1 Shared Variables............................. 13 v 2.1.1 Synchronization.......................... 13 2.1.2 Semaphores............................ 15 2.1.3 Conditional Critical Regions................... 17 2.1.4 Monitors.............................. 18 2.1.5 Futures.............................. 20 2.1.6 Action Systems.......................... 21 2.2 Message Passing.............................. 29 2.2.1 Asynchronous Message Passing................. 29 2.2.2 Synchronous Message Passing.................. 30 2.2.3 Implementations......................... 31 3 Lime 33 3.1 What is Lime............................... 33 3.2 Why Lime................................. 33 3.2.1 Actions.............................. 34 3.2.2 Methods.............................. 35 3.2.3 Method Calls........................... 36 3.3 Lime Syntax................................ 36 3.4 Lime Semantics.............................. 39 3.4.1 Core Language.......................... 39 3.4.2 Concurrent Objects........................ 43 3.5 Lime Examples.............................. 46 3.5.1 Semaphores............................ 46 3.5.2 Dining Philosophers....................... 46 3.5.3 Reader-Writer........................... 49 3.5.4 Delayed Doubler......................... 51 vi 3.5.5 Priority Queue.......................... 52 3.5.6 Leaf-oriented Trees........................ 54 4 Contributions to Lime 57 4.1 Previous Implementations of Lime.................... 57 4.1.1 Implementation of Lime Using Monitors............ 57 4.1.2 Implementation of Lime Using Condition Variables...... 58 4.2 The Addressed Problems......................... 58 4.2.1 Threads.............................. 58 4.2.2 Stack Mechanisms........................ 58 4.2.3 Guard Implementations..................... 59 4.3 Contributions of This Work....................... 59 4.3.1 Lime Compiler.......................... 59 4.3.2 Lime Runtime System...................... 60 5 Stack Mechanisms 63 5.1 Introduction................................ 63 5.2 Related Work............................... 64 5.2.1 Single-Threaded Call Stack................... 64 5.2.2 Shared Call Stacks........................ 66 5.2.3 Cactus Stacks........................... 66 5.2.4 Stack Mechanisms Summary................... 67 5.3 Experimental Setup............................ 68 5.4 Moore-Oliva's Lime Calling Convention................. 69 5.5 Implemented Stack Mechanisms..................... 70 5.5.1 Traditional Fixed-Size Stack with \Caller-cleanup"...... 70 5.5.2 Traditional Fixed-Size Stack with \Callee-cleanup"...... 71 vii 5.5.3 Per Procedure \Heap" Allocation................ 72 5.5.4 LookAhead Stack Mechanism.................. 72 5.5.5 Guard-Page Stack Mechanism.................. 73 5.6 Experiments................................ 75 5.6.1 Results............................... 77 5.6.2 Impact of Processor Architecture................ 78 5.6.3 Impact of Usage Profile in Single-Threaded Runs....... 78 5.6.4 Impact of Usage Profile in Multi-Threaded Runs........ 82 6 Guarded Commands in Lime 88 6.1 Lightweight Thread Implementations.................. 88 6.1.1 Erlang Process.......................... 88 6.1.2 Goroutine............................. 89 6.2 Previous Implementations of Guarded Commands in Lime...... 91 6.2.1 Busy Waiting........................... 92 6.2.2 Previous Implementations.................... 92 6.3 Guarded Commands Implementations.................. 93 6.3.1 Translation Schemes....................... 94 6.3.2 Context Switches......................... 96 6.3.3 Lime Runtime System...................... 97 6.4 Experiments................................ 102 6.4.1 Priority Queue.......................... 103 6.4.2 MapReduce............................ 105 6.4.3 Leaf-Oriented Tree........................ 107 6.4.4 The Santa Claus Problem.................... 110 6.4.5 The Chameneos Game...................... 113 viii 6.4.6 Summary............................. 116 7 Conclusions 118 A Priority Queue Examples 129 A.1 Erlang................................... 129 A.2 Go..................................... 130 A.3 Haskell................................... 132 A.4 Java.................................... 134 A.5 Pthread.................................. 137 B Leaf-oriented Tree Examples 142 B.1 Erlang................................... 142 B.2 Go..................................... 144 B.3 Haskell................................... 147 B.4 Java.................................... 149 B.5
Load more

Recommended publications
  • Probabilistic Models for the Guarded Command Language
    Science of Computer Programming ELSEVIER Science of Computer Programming 28 (1997) 171-192 Probabilistic models for the guarded command language He Jifeng *, K. Seidel, A. McIver Oxford University Computing Laboratory, Programming Research Group, 11 Keble. Road, Oxford OXI 3QD, UK Abstract The two models presented in this paper provide two different semantics for an extension of Dijkstra’s language of guarded commands. The extended language has an additional operator, namely probabilistic choice, which makes it possible to express randomized algorithms. An earlier model by Claire Jones included probabilistic choice but not non-determinism, which meant that it could not be used for the development of algorithms from specifications. Our second model is built on top of Claire Jones’ model, using a general method of extending a probabilistic cpo to one which abo contains non-determinism. The first model was constructed from scratch, as it were, guided only by the desire for certain algebraic properties of the language constructs, which we found lacking in the second model. We compare and contrast the properties of the two models both by giving examples and by constructing mappings between them and the non-probabilistic model. On the basis of this comparison we argue that, in general, the first model is preferable to the second. @ 1997 Elsevier Science B.V. Keywords: Probabilistic programming language; Semantics; Algebraic laws 1. Introduction Dijkstra’s language of guarded commands with its weakest precondition semantics [l] put reasoning about sequential imperative programs on a secure footing. The aim of this paper is to extend this language, its semantics, and formal reasoning to sequential randomized algorithms.
    [Show full text]
  • Active Object Systems Redacted for Privacy Abstract Approved
    AN ABSTRACT OF THE THESIS OF Sungwoon Choi for the degree of Doctor of Philosophyin Computer Science presented on February 6, 1992. Title: Active Object Systems Redacted for Privacy Abstract approved. v '" Toshimi Minoura An active object system isa transition-based object-oriented system suitable for the design of various concurrentsystems. An AOS consists of a collection of interacting objects, where the behavior of eachobject is determined by the transition statements provided in the class of that object.A transition statement is a condition-action pair, an equational assignmentstatement, or an event routine. The transition statements provided for eachobject can access, besides the state of that object, the states of the other objectsknown to it through its interface variables. Interface variablesare bound to objects when objects are instantiated so that desired connections among objects are established. The major benefit of the AOS approach is thatan active system can be hierarchically composed from its active software componentsas if it were a hardware system. An AOS provides better encapsulation andmore flexible communication protocols than ordinary object oriented systems, since control withinan AOS is localized. ©Copyright by Sungwoon Choi February 6, 1992 All Rights Reserved Active Object Systems by Sungwoon Choi A THESIS submitted to Oregon State University in partial fulfillment of the requirements for the degree of Doctor of Philosophy Completed February 6, 1992 Commencement June 1992 APPROVED: Redacted for Privacy Professor of Computer Science in charge ofmajor Redacted for Privacy Head of Department of Computer Science Redacted for Privacy Dean of Gradu to School Or Date thesis presented February 6, 1992 Typed by Sungwoon Choi for Sungwoon Choi To my wife Yejung ACKNOWLEDGEMENTS I would like to express my sincere gratitude tomy major professor, Dr.
    [Show full text]
  • An Overview of the Scala Programming Language
    An Overview of the Scala Programming Language Second Edition Martin Odersky, Philippe Altherr, Vincent Cremet, Iulian Dragos Gilles Dubochet, Burak Emir, Sean McDirmid, Stéphane Micheloud, Nikolay Mihaylov, Michel Schinz, Erik Stenman, Lex Spoon, Matthias Zenger École Polytechnique Fédérale de Lausanne (EPFL) 1015 Lausanne, Switzerland Technical Report LAMP-REPORT-2006-001 Abstract guage for component software needs to be scalable in the sense that the same concepts can describe small as well as Scala fuses object-oriented and functional programming in large parts. Therefore, we concentrate on mechanisms for a statically typed programming language. It is aimed at the abstraction, composition, and decomposition rather than construction of components and component systems. This adding a large set of primitives which might be useful for paper gives an overview of the Scala language for readers components at some level of scale, but not at other lev- who are familar with programming methods and program- els. Second, we postulate that scalable support for compo- ming language design. nents can be provided by a programming language which unies and generalizes object-oriented and functional pro- gramming. For statically typed languages, of which Scala 1 Introduction is an instance, these two paradigms were up to now largely separate. True component systems have been an elusive goal of the To validate our hypotheses, Scala needs to be applied software industry. Ideally, software should be assembled in the design of components and component systems. Only from libraries of pre-written components, just as hardware is serious application by a user community can tell whether the assembled from pre-fabricated chips.
    [Show full text]
  • Computing the Stabilization Times of Self-Stabilizing Systems
    IEICE TRANS. FUNDAMENTALS, VOL.E83–A, NO.11 NOVEMBER 2000 2245 PAPER Special Section on Concurrent Systems Technology Computing the Stabilization Times of Self-Stabilizing Systems Tatsuhiro TSUCHIYA†, Regular Member, Yusuke TOKUDA†, Nonmember, and Tohru KIKUNO†, Regular Member SUMMARY A distributed system is said to be self- state very fast. Research in this direction includes [1], stabilizing if it converges to some legitimate state from an ar- [8], [16]. bitrary state in a finite number of steps. The number of steps In this paper, we propose an automated method required for convergence is usually referred to as the ×ØabiÐiÞaØiÓÒ for computing the worst stabilization time, aiming at ØiÑe, and its reduction is one of the main performance issues in the design of self-stabilizing systems. In this paper, we propose supporting algorithm designers. In [6], Dolev et al. pro- an automated method for computing the stabilization time. The posed a theoretical method, called the scheduler luck method uses Boolean functions to represent the state space in game, for stabilization time analysis. This method can order to assuage the state explosion problem, and computes the stabilization time by manipulating the Boolean functions. To deal with randomized algorithms only, and it is not au- demonstrate the usefulness of the method, we apply it to the tomated. Some work addresses the issues of automatic analysis of existing self-stabilizing algorithms. The results show verification of self-stabilizing systems (e.g., [11], [12], that the method can perform stabilization time analysis very fast, [14]). To the best of our knowledge, however, there has even when an underlying state space is very huge.
    [Show full text]
  • Beyond Structured Programming
    Beyond Structured Programming M.H. van Emden Technical Report DCS-359-IR Department of Computer Science University of Victoria Abstract The correctness of a structured program is, at best, plausible. Though this is a step forward compared to what came before, it falls short of verified correctness. To verify a structured program according to Hoare’s method one is faced with the problem of finding assertions to fit existing code. In 1971 this mode of verification was declared by Dijkstra as too hard to be of practical use—he advised that proof and code were to grow together. A method for doing this was independently published by Reynolds in 1978 and by van Emden in 1979. The latter was further developed to attain the form of matrix code. This form of code not only obviates the need of fitting assertions to existing code, but helps in discovering an algorithm that reaches a given postcondition from a fixed precondition. In this paper a keyboard-editable version of matrix code is presented that uses E.W. Dijkstra’s guarded commands as starting point. The result is reached by using Floyd’s method rather than Hoare’s as starting point. 1 Introduction Structured Programming is the name of a method introduced by E.W. Dijkstra in 1969 [6]. At the time the method was revolutionary: it advocated the elimination of the goto statement and the ex- clusive use of conditional, alternative, and repetitive clauses. In a few years structured programming evolved from controversy to orthodoxy. C.A.R. Hoare invented a logic-based verification method for structured programs [13].
    [Show full text]
  • Notes on Functional Programming with Haskell
    Notes on Functional Programming with Haskell H. Conrad Cunningham [email protected] Multiparadigm Software Architecture Group Department of Computer and Information Science University of Mississippi 201 Weir Hall University, Mississippi 38677 USA Fall Semester 2014 Copyright c 1994, 1995, 1997, 2003, 2007, 2010, 2014 by H. Conrad Cunningham Permission to copy and use this document for educational or research purposes of a non-commercial nature is hereby granted provided that this copyright notice is retained on all copies. All other rights are reserved by the author. H. Conrad Cunningham, D.Sc. Professor and Chair Department of Computer and Information Science University of Mississippi 201 Weir Hall University, Mississippi 38677 USA [email protected] PREFACE TO 1995 EDITION I wrote this set of lecture notes for use in the course Functional Programming (CSCI 555) that I teach in the Department of Computer and Information Science at the Uni- versity of Mississippi. The course is open to advanced undergraduates and beginning graduate students. The first version of these notes were written as a part of my preparation for the fall semester 1993 offering of the course. This version reflects some restructuring and revision done for the fall 1994 offering of the course|or after completion of the class. For these classes, I used the following resources: Textbook { Richard Bird and Philip Wadler. Introduction to Functional Program- ming, Prentice Hall International, 1988 [2]. These notes more or less cover the material from chapters 1 through 6 plus selected material from chapters 7 through 9. Software { Gofer interpreter version 2.30 (2.28 in 1993) written by Mark P.
    [Show full text]
  • Modelling and Analysis of Communicating Systems (Chapter 4)
    Chapter 4 Sequential processes In chapter 2 we described behaviour by labelled transition systems. If behaviour be- comes more complex this technique falls short and we need a higher level syntax to concisely describe larger labelled transition systems. In this chapter we describe pro- cesses using an extended process algebra. The building blocks of our process algebra are (multi-)actions with data. We provide operators to combine behaviour in both a sequential and nondeterministic way and allow it to be controlled by data parameters. Axioms are used to characterise the meaning of the various constructs. The language that we get allows to describe all reactive behaviour. In the next chapter we define operators to combine behaviour in a more complex way, especially using the parallel operator. But these operators do not add to the expressivity of the language. The sort of all processes defined in this and the next chapter is P. 4.1 Actions As in chapter 2, actions are the basic ingredients of processes. More precisely, every action is an elementary process. Actions can carry data. E.g., a receive action can carry a message, and an error action can carry a natural number, for instance indicating its severity. Actions can have any number of parameters. They are declared as follows: act timeout ; error : N; receive : B × N+; This declares parameterless action name timeout , action name error with a data pa- rameter of sort N (natural numbers), and action name receive with two parameters of sort B (booleans) and N+ (positive numbers) respectively. For the above action name declaration, timeout , error (0) and receive (false , 6) are valid actions.
    [Show full text]
  • Active Object
    Active Object an Object Behavioral Pattern for Concurrent Programming R. Greg Lavender Douglas C. Schmidt [email protected] [email protected] ISODE Consortium Inc. Department of Computer Science Austin, TX Washington University, St. Louis An earlier version of this paper appeared in a chapter in the book ªPattern Languages of Program Design 2º ISBN 0-201-89527-7, edited by John Vlissides, Jim Coplien, and Norm Kerth published by Addison-Wesley, 1996. : Output : Input Handler Handler : Routing Table : Message Abstract Queue This paper describes the Active Object pattern, which decou- 3: enqueue(msg) ples method execution from method invocation in order to : Output 2: find_route(msg) simplify synchronized access to a shared resource by meth- Handler ods invoked in different threads of control. The Active Object : Message : Input pattern allows one or more independent threads of execution Queue Handler 1: recv(msg) to interleave their access to data modeled as a single ob- ject. A broad class of producer/consumer and reader/writer OUTGOING OUTGOING MESSAGES GATEWAY problems are well-suited to this model of concurrency. This MESSAGES pattern is commonly used in distributed systems requiring INCOMING INCOMING multi-threaded servers. In addition,client applications (such MESSAGES MESSAGES as windowing systems and network browsers), are increas- DST DST ingly employing active objects to simplify concurrent, asyn- SRC SRC chronous network operations. 1 Intent Figure 1: Connection-Oriented Gateway The Active Object pattern decouples method execution from method invocation in order to simplify synchronized access to a shared resource by methods invoked in different threads [2]. Sources and destinationscommunicate with the Gateway of control.
    [Show full text]
  • Insight, Inspiration and Collaboration
    Chapter 1 Insight, inspiration and collaboration C. B. Jones, A. W. Roscoe Abstract Tony Hoare's many contributions to computing science are marked by insight that was grounded in practical programming. Many of his papers have had a profound impact on the evolution of our field; they have moreover provided a source of inspiration to several generations of researchers. We examine the development of his work through a review of the development of some of his most influential pieces of work such as Hoare logic, CSP and Unifying Theories. 1.1 Introduction To many who know Tony Hoare only through his publications, they must often look like polished gems that come from a mind that rarely makes false steps, nor even perhaps has to work at their creation. As so often, this impres- sion is a further compliment to someone who actually adds to very hard work and many discarded attempts the final polish that makes complex ideas rel- atively easy for the reader to comprehend. As indicated on page xi of [HJ89], his ideas typically go through many revisions. The two authors of the current paper each had the honour of Tony Hoare supervising their doctoral studies in Oxford. They know at first hand his kind and generous style and will count it as an achievement if this paper can convey something of the working style of someone big enough to eschew competition and point scoring. Indeed it will be apparent from the following sections how often, having started some new way of thinking or exciting ideas, he happily leaves their exploration and development to others.
    [Show full text]
  • Inseguendo Fagiani Selvatici: Partial Order Reduction for Guarded Command Languages Frank S
    Inseguendo Fagiani Selvatici: Partial Order Reduction for Guarded Command Languages Frank S. de Boer CWI, Amsterdam, the Netherlands [email protected] Einar Broch Johnsen Department of Informatics, University of Oslo, Oslo, Norway einarj@ifi.uio.no Rudolf Schlatte Department of Informatics, University of Oslo, Oslo, Norway rudi@ifi.uio.no S. Lizeth Tapia Tarifa Department of Informatics, University of Oslo, Oslo, Norway sltarifa@ifi.uio.no Lars Tveito Department of Informatics, University of Oslo, Oslo, Norway larstvei@ifi.uio.no Abstract This paper presents a method for testing whether objects in actor languages and active object languages exhibit locally deterministic behavior. We investigate such a method for a class of guarded command programs, abstracting from object-oriented features like method calls but focusing on cooperative scheduling of dynamically spawned processes executing in parallel. The proposed method can answer questions such as whether all permutations of an execution trace are equivalent, by generating candidate traces for testing which may lead to different final states. To prune the set of candidate traces, we employ partial order reduction. To further reduce the set, we introduce an analysis technique to decide whether a generated trace is schedulable. Schedulability cannot be decided for guarded commands using standard dependence and interference relations because guard enabledness is non-monotonic. To solve this problem, we use concolic execution to produce linearized symbolic traces of the executed program, which
    [Show full text]
  • Open Pattern Matching for C++
    Open Pattern Matching for C++ Yuriy Solodkyy Gabriel Dos Reis Bjarne Stroustrup Texas A&M University College Station, Texas, USA fyuriys,gdr,[email protected] Abstract 1.1 Summary Pattern matching is an abstraction mechanism that can greatly sim- We present functional-style pattern matching for C++ built as an plify source code. We present functional-style pattern matching for ISO C++11 library. Our solution: C++ implemented as a library, called Mach71. All the patterns are • is open to the introduction of new patterns into the library, while user-definable, can be stored in variables, passed among functions, not making any assumptions about existing ones. and allow the use of class hierarchies. As an example, we imple- • is type safe: inappropriate applications of patterns to subjects ment common patterns used in functional languages. are compile-time errors. Our approach to pattern matching is based on compile-time • Makes patterns first-class citizens in the language (§3.1). composition of pattern objects through concepts. This is superior • is non-intrusive, so that it can be retroactively applied to exist- (in terms of performance and expressiveness) to approaches based ing types (§3.2). on run-time composition of polymorphic pattern objects. In partic- • provides a unified syntax for various encodings of extensible ular, our solution allows mapping functional code based on pattern hierarchical datatypes in C++. matching directly into C++ and produces code that is only a few • provides an alternative interpretation of the controversial n+k percent slower than hand-optimized C++ code. patterns (in line with that of constructor patterns), leaving the The library uses an efficient type switch construct, further ex- choice of exact semantics to the user (§3.3).
    [Show full text]
  • CS 11 Haskell Track: Lecture 1 N This Week
    CS 11 Haskell track: lecture 1 n This week: n Introduction/motivation/pep talk n Basics of Haskell Prerequisite n Knowledge of basic functional programming n e.g. Scheme, Ocaml, Erlang n CS 1, CS 4 n "permission of instructor" n Without this, course will be pretty hard Quote "Any programming language that doesn't change the way you think about programming is not worth learning." -- Alan Perlis Why learn Haskell? (1) n Pound for pound, Haskell has more novel concepts than any programming language I've ever seen n and I've seen 'em all n Very powerful and innovative type system n Extremely high-level language n Will make you smarter n Fun to program in! Why learn Haskell? (2) n Very elegant and concise code: quicksort :: (Ord a) => [a] -> [a] quicksort [] = [] quicksort (x:xs) = quicksort lt ++ [x] ++ quicksort ge where lt = [y | y <- xs, y < x] ge = [y | y <- xs, y >= x] n Works for any orderable type What Haskell is good at n Any problem that can be characterized as a transformation n Compilers n DSLs (Domain-Specific Languages) n Implementing mathematical/algebraic concepts n Theorem provers What Haskell is not good at n Any problem that requires extreme speed n unless you use Haskell to generate C code n Any problem that is extremely stateful n e.g. simulations n though monads can get around this to some extent What is Haskell, anyway? n Haskell is a programming language n duh n A functional programming language n you all know what that is n A lazy functional programming language n Has strong static typing n every expression has a type n all types checked at compile time What is Haskell, anyway? n Named after Haskell Curry n pioneer in mathematical logic n developed theory of combinators n S, K, I and fun stuff like that Laziness (1) n Lazy evaluation means expressions (e.g.
    [Show full text]