DOCSLIB.ORG

Conception, Evolution, and Application of Functional Programming Languages

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Conception, Evolution, and Application of Functional Programming Languages Conception, Evolution, and Application of Functional Programming Languages PAUL HUDAK Yale University, Department of Computer Science, New Haven, Connecticut 06520 The foundations of functional programming languages are examined from both historical and technical perspectives. Their evolution is traced through several critical periods: early work on lambda calculus and combinatory calculus, Lisp, Iswim, FP, ML, and modern functional languages such as Miranda’ and Haskell. The fundamental premises on which the functional programming methodology stands are critically analyzed with respect to philosophical, theoretical, and pragmatic concerns. Particular attention is paid to the main features that characterize modern functional languages: higher-order functions, lazy evaluation, equations and pattern matching, strong static typing and type inference, and data abstraction. In addition, current research areas-such as parallelism, nondeterminism, input/output, and state-oriented computations-are examined with the goal of predicting the future development and application of functional languages. Categories and Subject Descriptors: D.l.l [Programming Techniques]: Applicative (Functional) Programming; D.3.2 [Programming Languages]: Language Classifications-applicative languages; data-flow languages; nonprocedural languages; very high-level languages; F.4.1 [Mathematical Logic and Formal Languages]: Mathematical Logic-lambda calculus and related systems; K.2 [History of Computing]: Software General Terms: Languages Additional Key Words and Phrases: Data abstraction, higher-order functions, lazy evaluation, referential transparency, types INTRODUCTION ent kinds of machines increased, the need The earliest programming languages were arose for a common language with which to developed with one simple goal in mind: to program all of them. provide a vehicle through which one could Thus from primitive assembly lan- control the behavior of computers. Not sur- guages (which were at least a step up from prisingly, the early languages reflected the raw machine code) there grew a plethora of structure of the underlying machines fairly high-level programming languages, begin- well. Although at first blush that goal ning with FORTRAN in the 1950s. The seems eminently reasonable, the viewpoint development of these languages grew so quickly changed for two very good reasons. rapidly that by the 1980s they were best First, it became obvious that what was easy characterized by grouping them into fami- for a machine to reason about was not lies that reflected a common computation necessarily easy for a human being to rea- model or programming style. Debates over son about. Second, as the number of differ- which language or family of languages is best will undoubtedly persist for as long as 1 Miranda is a trademark of Research Software Ltd. computers need programmers. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. 0 1989 ACM 0360-0300/89/0900-0359 $01.50 ACM Computing Surveys, Vol. 21, No. 3, September 1989 360 . Paul Hudak CONTENTS the significant interest current researchers have in functional languages and the im- pact they have had on both the theory and pragmatics of programming languages in INTRODUCTION general. Programming Language Spectrum Among the claims made by functional Referential Transparency and Equational language advocates are that programs can Reasoning Plan of Study be written quicker, are more concise, are 1. EVOLUTION OF FUNCTIONAL LANGUAGES higher level (resembling more closely tra- 1.1 Lambda Calculus ditional mathematical notation), are more 1.2 Lisp amenable to formal reasoning and analysis, 1.3 Iswim 1.4 APL and can be executed more easily on parallel 1.5 FP architectures. Of course, many of these fea- 1.6 ML tures touch on rather subjective issues, 1.7 SASL, KRC, and Miranda which is one reason why the debates can be 1.8 Dataflow Languages so lively. 1.9 Others 1.10 Haskell This paper gives the reader significant 2. DISTINGUISHING FEATURES OF MODERN insight into the very essence of functional FUNCTIONAL LANGUAGES languages and the programming method- 2.1 Higher Order Functions ology that they support. It starts with a 2.2 Nonstrict Semantics (Lazy Evaluating) 2.3 Data Abstraction discussion of the nature of functional lan- 2.4 Equations and Pattern Matching guages, followed by an historical sketch of 2.5 Formal Semantics their development, a summary of the dis- 3. ADVANCED FEATURES AND ACTIVE tinguishing characteristics of modern func- RESEARCH AREAS tional languages, and a discussion of 3.1 Overloading 3.2 Purely Functional Yet Universal I/O current research areas. Through this study 3.3 Arrays we will put into perspective both the power 3.4 Views and weaknesses of the functional program- 3.5 Parallel Functional Programming ming paradigm. 3.6 Caching and Memoization 3.7 Nondeterminism A Note to the Reader: This paper as- 3.8 Extensions to Polymorphic-Type Inference sumes a good understanding of the funda- 3.9 Combining Other Programming Language mental issues in programming language Paradigms design and use. To learn more about mod- 4. DISPELLING MYTHS ABOUT FUNCTIONAL ern functional programming techniques, PROGRAMMING 5. CONCLUSIONS including the important ideas behind rea- REFERENCES soning about functional programs, refer to Bird and Wadler [1988] or Field and Har- rison [1988]. To read about how to imple- ment functional languages, see Peyton Jones [ 19871 (additional references are The class of functional, or applicative, given in Sections 1.8 and 5). programming languages, in which compu- Finally, a comment on notation: Unless tation is carried out entirely through the otherwise stated, all examples will be writ- evaluation of expressions, is one such fam- ten in Haskell, a recently proposed func- ily of languages, and debates over its merits tional language standard [Hudak and have been quite lively in recent years. Are Wadler 19881. Explanations will be given functional languages toys? Or are they in square brackets [ ] as needed.’ tools? Are they artifacts of theoretical fan- tasy or of visionary pragmatism? Will they ‘Since the Haskell Report is relatively new, some ameliorate software woes or merely com- minor changes to the language may occur after this pound them? Whatever answers we might paper has appeared. An up-to-date copy of the Report have for these questions, we cannot ignore may be obtained from the author. ACM Computing Surveys, Vol. 21, NO. 3, September 1989 Functional Programming Languages 361 Programming Language Spectrum in the functional language Haskell by Imperative languages are characterized as fat x 1 having an implicit state that is modified where fat n a (i.e., side effected) by constructs (i.e., com- = if n>O then fat (n-l) (a*n) mands) in the source language. As a result, else a such languages generally have a notion of in which the formal parameters n and a are sequencing (of the commands) to permit examples of carrying the state around ex- precise and deterministic control over plicitly, and the recursive structure has the state. Most, including the most pop- been arranged so as to mimic as closely as ular, languages in existence today are possible the looping behavior of the pro- imperative. gram given earlier. Note that the condi- As an example, the assignment state- tional in this program is an expression ment is a (very common) command, since rather than command; that is, it denotes a its effect is to alter the underlying implicit value (conditional on the value of the pred- store so as to yield a different binding for icate) rather than a sequencer of com- a particular variable. The begin . end mands. Indeed the value of the program is construct is the prototypical sequencer of the desired factorial, rather than it being commands, as are the well-known goto found in an implicit store. statement (unconditional transfer of con- Functional (in general, declarative) pro- trol), conditional statement (qualified se- gramming is often described as expressing quencer), and while loop (an example of a what is being computed rather than how, structured command). With these simple although this is really a matter of degree. forms, we can, for example, compute the For example, the above program may say factorial of the number X: less about how factorial is computed than the imperative program given earlier, but n:= x; is perhaps not as abstract as a := 1; while n>O do fat x begin a := a*n; where fat n n := n-l = if n==O then 1 end; else n*fac (n-l) [== is the infix operator for equality], which appears very much like the mathe- After execution of this program, the value matical definition of factorial and is indeed of a in the implicit store will contain the a valid functional program. desired result. Since most languages have expressions, In contrast, declarative languages are it is tempting to take our definitions liter- characterized as having no implicit state, ally and describe functional languages via and thus the emphasis is placed entirely on derivation from conventional programming programming with expressions (or terms). languages: Simply drop the assignment In particular, functional languages are dec- statement and any other side-effecting larative languages whose underlying model primitives. This approach, of course, is very of computation is the function (in contrast misleading. The result of such a derivation to, for example, the relation that forms the is usually far less than satisfactory, since basis for logic programming languages). the purely functional subset of most im- perative languages is hopelessly weak In a declarative language state-oriented (although there are important exceptions, computations are accomplished by carrying such as Scheme [Rees and Clinger 19861).
Load more

Recommended publications
  • Structure Interpretation of Text Formats
    1 1 Structure Interpretation of Text Formats 2 3 SUMIT GULWANI, Microsoft, USA 4 VU LE, Microsoft, USA 5 6 ARJUN RADHAKRISHNA, Microsoft, USA 7 IVAN RADIČEK, Microsoft, Austria 8 MOHAMMAD RAZA, Microsoft, USA 9 Data repositories often consist of text files in a wide variety of standard formats, ad-hoc formats, aswell 10 mixtures of formats where data in one format is embedded into a different format. It is therefore a significant 11 challenge to parse these files into a structured tabular form, which is important to enable any downstream 12 data processing. 13 We present Unravel, an extensible framework for structure interpretation of ad-hoc formats. Unravel 14 can automatically, with no user input, extract tabular data from a diverse range of standard, ad-hoc and 15 mixed format files. The framework is also easily extensible to add support for previously unseen formats, 16 and also supports interactivity from the user in terms of examples to guide the system when specialized data extraction is desired. Our key insight is to allow arbitrary combination of extraction and parsing techniques 17 through a concept called partial structures. Partial structures act as a common language through which the file 18 structure can be shared and refined by different techniques. This makes Unravel more powerful than applying 19 the individual techniques in parallel or sequentially. Further, with this rule-based extensible approach, we 20 introduce the novel notion of re-interpretation where the variety of techniques supported by our system can 21 be exploited to improve accuracy while optimizing for particular quality measures or restricted environments.
    [Show full text]
  • The Marriage of Effects and Monads
    The Marriage of Effects and Monads PHILIP WADLER Avaya Labs and PETER THIEMANN Universit¨at Freiburg Gifford and others proposed an effect typing discipline to delimit the scope of computational ef- fects within a program, while Moggi and others proposed monads for much the same purpose. Here we marry effects to monads, uniting two previously separate lines of research. In partic- ular, we show that the type, region, and effect system of Talpin and Jouvelot carries over di- rectly to an analogous system for monads, including a type and effect reconstruction algorithm. The same technique should allow one to transpose any effect system into a corresponding monad system. Categories and Subject Descriptors: D.3.1 [Programming Languages]: Formal Definitions and Theory; F.3.2 [Logics and Meanings of Programs]: Semantics of Programming Languages— Operational semantics General Terms: Languages, Theory Additional Key Words and Phrases: Monad, effect, type, region, type reconstruction 1. INTRODUCTION Computational effects, such as state or continuations, are powerful medicine. If taken as directed they may cure a nasty bug, but one must be wary of the side effects. For this reason, many researchers in computing seek to exploit the benefits of computational effects while delimiting their scope. Two such lines of research are the effect typing discipline, proposed by Gifford and Lucassen [Gifford and Lucassen 1986; Lucassen 1987], and pursued by Talpin and Jouvelot [Talpin and Jouvelot 1992, 1994; Talpin 1993] among others, and the use of monads, proposed by Moggi [1989, 1990], and pursued by Wadler [1990, 1992, 1993, 1995] among others. Effect systems are typically found in strict languages, such as FX [Gifford et al.
    [Show full text]
  • Installing Visual Flagship for MS-Windows
    First Steps with Visual FlagShip 8 for MS-Windows 1. Requirements This instruction applies for FlagShip port using Microsoft Visual Studio 2017 (any edition, also the free Community), or the Visual Studio 2015. The minimal requirements are: • Microsoft Windows 32bit or 64bit operating system like Windows-10 • 2 GB RAM (more is recommended for performance) • 300 MB free hard disk space • Installed Microsoft MS-Visual Studio 2017 or 2015 (see step 2). It is re- quired for compiling .c sources and to link with corresponding FlagShip library. This FlagShip version will create 32bit or 64bit objects and native executables (.exe files) applicable for MS-Windows 10 and newer. 2. Install Microsoft Visual Studio 2017 or 2015 If not available yet, download and install Microsoft Visual Studio, see this link for details FlagShip will use only the C/C++ (MS-VC) compiler and linker from Visual Studio 2017 (or 2015) to create 64-bit and/or 32- bit objects and executables from your sources. Optionally, check the availability and the correct version of MS-VC compiler in CMD window (StartRuncmd) by invoking C:\> cd "C:\Program Files (x86)\Microsoft Visual Studio\ 2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64" C:\> CL.exe should display: Microsoft (R) C/C++ Optimizing Compiler Version 19.10.25019 for x64 Don’t worry if you can invoke CL.EXE only directly with the path, FlagShip’s Setup will set the proper path for you. Page 1 3. Download FlagShip In your preferred Web-Browser, open http://www.fship.com/windows.html and download the Visual FlagShip setup media using MS-VisualStudio and save it to any folder of your choice.
    [Show full text]
  • Functional Programming Is Style of Programming in Which the Basic Method of Computation Is the Application of Functions to Arguments;
    PROGRAMMING IN HASKELL Chapter 1 - Introduction 0 What is a Functional Language? Opinions differ, and it is difficult to give a precise definition, but generally speaking: • Functional programming is style of programming in which the basic method of computation is the application of functions to arguments; • A functional language is one that supports and encourages the functional style. 1 Example Summing the integers 1 to 10 in Java: int total = 0; for (int i = 1; i 10; i++) total = total + i; The computation method is variable assignment. 2 Example Summing the integers 1 to 10 in Haskell: sum [1..10] The computation method is function application. 3 Historical Background 1930s: Alonzo Church develops the lambda calculus, a simple but powerful theory of functions. 4 Historical Background 1950s: John McCarthy develops Lisp, the first functional language, with some influences from the lambda calculus, but retaining variable assignments. 5 Historical Background 1960s: Peter Landin develops ISWIM, the first pure functional language, based strongly on the lambda calculus, with no assignments. 6 Historical Background 1970s: John Backus develops FP, a functional language that emphasizes higher-order functions and reasoning about programs. 7 Historical Background 1970s: Robin Milner and others develop ML, the first modern functional language, which introduced type inference and polymorphic types. 8 Historical Background 1970s - 1980s: David Turner develops a number of lazy functional languages, culminating in the Miranda system. 9 Historical Background 1987: An international committee starts the development of Haskell, a standard lazy functional language. 10 Historical Background 1990s: Phil Wadler and others develop type classes and monads, two of the main innovations of Haskell.
    [Show full text]
  • Integrating Stream Parallelism and Task Parallelism in a Dataflow Programming Model
    RICE UNIVERSITY Integrating Stream Parallelism and Task Parallelism in a Dataflow Programming Model by Drago¸sDumitru Sb^ırlea A Thesis Submitted in Partial Fulfillment of the Requirements for the Degree Master of Science Approved, Thesis Committee: Vivek Sarkar Professor of Computer Science E.D. Butcher Chair in Engineering Keith D. Cooper L. John and Ann H. Doerr Professor of Computational Engineering Lin Zhong Associate Professor of Electrical and Computer Engineering Jun Shirako Research Scientist Computer Science Department Houston, Texas September 3rd, 2011 ABSTRACT Integrating Stream Parallelism and Task Parallelism in a Dataflow Programming Model by Drago¸sDumitru Sb^ırlea As multicore computing becomes the norm, exploiting parallelism in applications becomes a requirement for all software. Many applications exhibit different kinds of parallelism, but most parallel programming languages are biased towards a specific paradigm, of which two common ones are task and streaming parallelism. This results in a dilemma for programmers who would prefer to use the same language to exploit different paradigms for different applications. Our thesis is an integration of stream- parallel and task-parallel paradigms can be achieved in a single language with high programmability and high resource efficiency, when a general dataflow programming model is used as the foundation. The dataflow model used in this thesis is Intel's Concurrent Collections (CnC). While CnC is general enough to express both task-parallel and stream-parallel paradigms, all current implementations of CnC use task-based runtime systems that do not de- liver the resource efficiency expected from stream-parallel programs. For streaming programs, this use of a task-based runtime system is wasteful of computing cycles and makes memory management more difficult than it needs to be.
    [Show full text]
  • Introduction for Position ID Senior C++ Developer 11611
    Introduction for position Senior C++ Developer ID 11611 CURRICULUM VITAE Place of Residence Stockholm Profile A C++ programming expert with consistent success on difficult tasks. Expert in practical use of C++ (25+ years), C++11, C++14, C++17 integration with C#, Solid Windows, Linux, Minimal SQL. Dated experience with other languages, including assemblers. Worked in a number of domains, including finance, business and industrial automation, software development tools. Skills & Competences - Expert with consistent success on difficult tasks, dedicated and team lead in various projects. - Problems solving quickly, sometimes instantly; - Manage how to work under pressure. Application Software - Excellent command of the following software: Solid Windows, Linux. Minimal SQL. - Use of C++ (25+ years), C++11, C++14, C++17 integration with C#. Education High School Work experience Sep 2018 – Present Expert C++ Programmer – Personal Project Your tasks/responsibilities - Continuing personal project: writing a parser for C++ language, see motivation in this CV after the Saxo Bank job. - Changed implementation language from Scheme to C++. Implemented a C++ preprocessor of decent quality, extractor of compiler options from a MS Visual Studio projects. - Generated the formal part of the parser from a publicly available grammar. - Implemented “pack rat” optimization for the (recursive descent) parser. - Implementing a parsing context data structure efficient for recursive descent approach; the C++ name lookup algorithm.- Implementing a parsing context data structure efficient for recursive descent approach; the C++ name lookup algorithm. May 2015 – Sep 2018 C++ Programmer - Stockholm Your tasks/responsibilities - Provided C++ expertise to an ambitious company developing a fast database engine and a business software platform.
    [Show full text]
  • Dataflow Programming Model for Reconfigurable Computing Laurent Gantel, Amel Khiar, Benoît Miramond, Mohamed El Amine Benkhelifa, Fabrice Lemonnier, Lounis Kessal
    Dataflow Programming Model For Reconfigurable Computing Laurent Gantel, Amel Khiar, Benoît Miramond, Mohamed El Amine Benkhelifa, Fabrice Lemonnier, Lounis Kessal To cite this version: Laurent Gantel, Amel Khiar, Benoît Miramond, Mohamed El Amine Benkhelifa, Fabrice Lemonnier, et al.. Dataflow Programming Model For Reconfigurable Computing. 6th International Workshop on Reconfigurable Communication-centric Systems-on-Chip (ReCoSoC), Jun 2011, Montpellier, France. pp.1-8, 10.1109/ReCoSoC.2011.5981505. hal-00623674 HAL Id: hal-00623674 https://hal.archives-ouvertes.fr/hal-00623674 Submitted on 14 Sep 2011 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. Dataflow Programming Model For Reconfigurable Computing L. Gantel∗† and A. Khiar∗ and B. Miramond∗ and A. Benkhelifa∗ and F. Lemonnier† and L. Kessal∗ ∗ ETIS Laboratory – UMR CNRS 8051 † Embedded System Lab Universityof Cergy-Pontoise/ ENSEA Thales Research and Technology 6,avenueduPonceau 1,avenueAugustinFresnel 95014 Cergy-Pontoise, FRANCE 91767 Palaiseau, FRANCE Email {firstname.name}@ensea.fr Email {firstname.name}@thalesgroup.com Abstract—This paper addresses the problem of image process- system, such as sockets. ing algorithms implementation onto dynamically and reconfig- It reduces significantly the work of application programmers urable architectures. Today, these Systems-on-Chip (SoC), offer by relieving them of tedious and error-prone programming.
    [Show full text]
  • The Power of Higher-Order Composition Languages in System Design
    The Power of Higher-Order Composition Languages in System Design James Adam Cataldo Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2006-189 http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-189.html December 18, 2006 Copyright © 2006, 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. The Power of Higher-Order Composition Languages in System Design by James Adam Cataldo B.S. (Washington University in St. Louis) 2001 M.S. (University of California, Berkeley) 2003 A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Electrical Engineering in the GRADUATE DIVISION of the UNIVERSITY OF CALIFORNIA, BERKELEY Committee in charge: Professor Edward Lee, Chair Professor Alberto Sangiovanni-Vincentelli Professor Raja Sengupta Fall 2006 The dissertation of James Adam Cataldo is approved: Chair Date Date Date University of California, Berkeley Fall 2006 The Power of Higher-Order Composition Languages in System Design Copyright 2006 by James Adam Cataldo 1 Abstract The Power of Higher-Order Composition Languages in System Design by James Adam Cataldo Doctor of Philosophy in Electrical Engineering University of California, Berkeley Professor Edward Lee, Chair This dissertation shows the power of higher-order composition languages in system design.
    [Show full text]
  • A Critique of Abelson and Sussman Why Calculating Is Better Than
    A critique of Abelson and Sussman - or - Why calculating is better than scheming Philip Wadler Programming Research Group 11 Keble Road Oxford, OX1 3QD Abelson and Sussman is taught [Abelson and Sussman 1985a, b]. Instead of emphasizing a particular programming language, they emphasize standard engineering techniques as they apply to programming. Still, their textbook is intimately tied to the Scheme dialect of Lisp. I believe that the same approach used in their text, if applied to a language such as KRC or Miranda, would result in an even better introduction to programming as an engineering discipline. My belief has strengthened as my experience in teaching with Scheme and with KRC has increased. - This paper contrasts teaching in Scheme to teaching in KRC and Miranda, particularly with reference to Abelson and Sussman's text. Scheme is a "~dly-scoped dialect of Lisp [Steele and Sussman 19781; languages in a similar style are T [Rees and Adams 19821 and Common Lisp [Steele 19821. KRC is a functional language in an equational style [Turner 19811; its successor is Miranda [Turner 1985k languages in a similar style are SASL [Turner 1976, Richards 19841 LML [Augustsson 19841, and Orwell [Wadler 1984bl. (Only readers who know that KRC stands for "Kent Recursive Calculator" will have understood the title of this There are four language features absent in Scheme and present in KRC/Miranda that are important: 1. Pattern-matching. 2. A syntax close to traditional mathematical notation. 3. A static type discipline and user-defined types. 4. Lazy evaluation. KRC and SASL do not have a type discipline, so point 3 applies only to Miranda, Philip Wadhr Why Calculating is Better than Scheming 2 b LML,and Orwell.
    [Show full text]
  • Machine Learning with Multiscale Dataflow Computing for High Energy Physics
    Machine Learning with Multiscale Dataflow Computing for High Energy Physics 10.7.2019 Outline • Dataflow Concept and Maxeler • Dataflow for ML and Use Cases • Dataflow Programming Introduction • Hands-on Example 2 Dataflow Concept and Maxeler 10.7.2019 Programmable Spectrum Control-flow processors Dataflow processor GK110 Single-Core CPU Multi-Core Several-Cores Many-Cores Dataflow Increasing Parallelism (#cores) Increasing Core Complexity ( Hardware Clock Frequency ) GPU (NVIDIA, AMD) Intel, AMD Tilera, XMOS etc... Maxeler Hybrid e.g. AMD Fusion, IBM Cell 4 Maxeler Dataflow Engines (DFEs) • Largest Reconfigurable DataflowLMEM Engine (DFE) (Large Memory) Chip 4-96GB MaxRing • O(1k) multipliers High bandwidth memory link Interconnect • O(100k) logic cells Reconfigurable compute fabric • O(10MB) of on-chip SRAM MaxRing Dataflow cores & * links FMEM (fast • O(10GB) of on-card DRAM memory) • DFE-to-DFE interconnect Link to main data network * approaching 128GB on a ¾, single slot PCIe card 5 5 Maxeler Dataflow Engines (DFEs) CPU DFE (Dataflow Engine) 6 Control Flow versus Data Flow • Control Flow: • It is all about how instructions “move” • Data may move along with instructions (secondary issue) • Order of computation is the key • Data Flow: • It is about how data moves through a set of “instructions” in 2D space • Data moves will trigger control • Data availability, transformations and operation latencies are the key 7 Area Utilisation of Modern Chips AMD Bulldozer CPU Nvidia Tesla V100 GPU 8 DFE Area Utilisation 9 Dataflow Computing • A custom chip for a specific application • No instructions ➝ no instruction decode logic • No branches ➝ no branch prediction • Explicit parallelism ➝ no out-of-order scheduling • Data streamed onto-chip ➝ no multi-level caches Memory (Lots (Lots of) Rest of the My Dataflow world Engine 10 Dataflow Computing • Single worker builds a single • Each component is added to bicycle from a group of parts the bicycle in a production line.
    [Show full text]
  • Comparative Studies of Programming Languages; Course Lecture Notes
    Comparative Studies of Programming Languages, COMP6411 Lecture Notes, Revision 1.9 Joey Paquet Serguei A. Mokhov (Eds.) August 5, 2010 arXiv:1007.2123v6 [cs.PL] 4 Aug 2010 2 Preface Lecture notes for the Comparative Studies of Programming Languages course, COMP6411, taught at the Department of Computer Science and Software Engineering, Faculty of Engineering and Computer Science, Concordia University, Montreal, QC, Canada. These notes include a compiled book of primarily related articles from the Wikipedia, the Free Encyclopedia [24], as well as Comparative Programming Languages book [7] and other resources, including our own. The original notes were compiled by Dr. Paquet [14] 3 4 Contents 1 Brief History and Genealogy of Programming Languages 7 1.1 Introduction . 7 1.1.1 Subreferences . 7 1.2 History . 7 1.2.1 Pre-computer era . 7 1.2.2 Subreferences . 8 1.2.3 Early computer era . 8 1.2.4 Subreferences . 8 1.2.5 Modern/Structured programming languages . 9 1.3 References . 19 2 Programming Paradigms 21 2.1 Introduction . 21 2.2 History . 21 2.2.1 Low-level: binary, assembly . 21 2.2.2 Procedural programming . 22 2.2.3 Object-oriented programming . 23 2.2.4 Declarative programming . 27 3 Program Evaluation 33 3.1 Program analysis and translation phases . 33 3.1.1 Front end . 33 3.1.2 Back end . 34 3.2 Compilation vs. interpretation . 34 3.2.1 Compilation . 34 3.2.2 Interpretation . 36 3.2.3 Subreferences . 37 3.3 Type System . 38 3.3.1 Type checking . 38 3.4 Memory management .
    [Show full text]
  • Graceful Language Extensions and Interfaces
    Graceful Language Extensions and Interfaces by Michael Homer A thesis submitted to the Victoria University of Wellington in fulfilment of the requirements for the degree of Doctor of Philosophy Victoria University of Wellington 2014 Abstract Grace is a programming language under development aimed at ed- ucation. Grace is object-oriented, imperative, and block-structured, and intended for use in first- and second-year object-oriented programming courses. We present a number of language features we have designed for Grace and implemented in our self-hosted compiler. We describe the design of a pattern-matching system with object-oriented structure and minimal extension to the language. We give a design for an object-based module system, which we use to build dialects, a means of extending and restricting the language available to the programmer, and of implementing domain-specific languages. We show a visual programming interface that melds visual editing (à la Scratch) with textual editing, and that uses our dialect system, and we give the results of a user experiment we performed to evaluate the usability of our interface. ii ii Acknowledgments The author wishes to acknowledge: • James Noble and David Pearce, his supervisors; • Andrew P. Black and Kim B. Bruce, the other designers of Grace; • Timothy Jones, a coauthor on a paper forming part of this thesis and contributor to Minigrace; • Amy Ruskin, Richard Yannow, and Jameson McCowan, coauthors on other papers; • Daniel Gibbs, Jan Larres, Scott Weston, Bart Jacobs, Charlie Paucard, and Alex Sandilands, other contributors to Minigrace; • Gilad Bracha, Matthias Felleisen, and the other (anonymous) review- ers of papers forming part of this thesis; • the participants in his user study; • David Streader, John Grundy, and Laurence Tratt, examiners of the thesis; • and Alexandra Donnison, Amy Chard, Juanri Barnard, Roma Kla- paukh, and Timothy Jones, for providing feedback on drafts of this thesis.
    [Show full text]