Julia's Efficient Algorithm for Subtyping Unions and Covariant Tuples

Total Page:16

File Type:pdf, Size:1020Kb

Julia's Efficient Algorithm for Subtyping Unions and Covariant Tuples Julia’s efficient algorithm for subtyping unions and covariant tuples (Pearl) Benjamin Chung, Francesco Zappa Nardelli, Jan Vitek To cite this version: Benjamin Chung, Francesco Zappa Nardelli, Jan Vitek. Julia’s efficient algorithm for subtyping unions and covariant tuples (Pearl). ECOOP 2019 - 33rd European Conference of Object-Oriented Programming, Jul 2019, London, United Kingdom. 10.4230/LIPIcs.ECOOP.2019.6. hal-02297696 HAL Id: hal-02297696 https://hal.inria.fr/hal-02297696 Submitted on 26 Sep 2019 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. 1 Julia’s efficient algorithm for subtyping unions and 2 covariant tuples (Pearl) 3 Benjamin Chung 4 Northeastern University 5 Francesco Zappa Nardelli 6 Inria 7 Jan Vitek 8 Northeastern University & Czech Technical University in Prague 9 Abstract 10 The Julia programming language supports multiple dispatch and provides a rich type annotation 11 language to specify method applicability. When multiple methods are applicable for a given call, 12 Julia relies on subtyping between method signatures to pick the correct method to invoke. Julia’s 13 subtyping algorithm is surprisingly complex, and determining whether it is correct remains an open 14 question. In this paper, we focus on one piece of this problem: the interaction between union 15 types and covariant tuples. Previous work normalized unions inside tuples to disjunctive normal 16 form. However, this strategy has two drawbacks: complex type signatures induce space explosion, 17 and interference between normalization and other features of Julia’s type system. In this paper, 18 we describe the algorithm that Julia uses to compute subtyping between tuples and unions—an 19 algorithm that is immune to space explosion and plays well with other features of the language. We 20 prove this algorithm correct and complete against a semantic-subtyping denotational model in Coq. 21 2012 ACM Subject Classification Theory of computation → Type theory 22 Keywords and phrases Type systems, Subtyping, Union types 23 Digital Object Identifier 10.4230/LIPIcs.ECOOP.2019.6 24 Category Pearl 25 1 Introduction 26 Union types, originally introduced by Barbanera and Dezani-Ciancaglini [2], are being 27 adopted in mainstream languages. In some cases, such as Julia [5] or TypeScript [11], they 28 are exposed at the source level. In others, such as Hack [8], they are only used internally as 29 part of type inference. As a result, subtyping algorithms between union types are of increasing 30 practical import. The standard subtyping algorithm for this combination of features has, for 31 some time, been exponential in both time and space. An alternative algorithm, linear in space 32 but still exponential in time, has been tribal knowledge in the subtyping community [15]. In 33 this paper, we describe and prove correct an implementation of that algorithm. 34 We observed the algorithm in our prior work formalizing the Julia subtyping relation [17]. 35 There, we described Julia’s subtyping relation as it arose from its decision procedure but were 36 unable to prove it correct. Indeed, we found bugs in the Julia implementation and identified 37 unresolved correctness issues. Contemporary work addresses some correctness concerns [3] 38 but leaves algorithmic correctness open. 39 Julia’s subtyping algorithm [4] is used for method dispatch. While Julia is dynamically 40 typed, method arguments can have type annotations. These annotations allow one method 41 to be implemented by multiple functions. At run time, Julia searches for the most specific 42 applicable function for a given invocation. Consider these declarations of multiplication: 43 © Benjamin Chung, Francesco Zappa Nardelli, Jan Vitek; licensed under Creative Commons License CC-BY 33rd European Conference on Object-Oriented Programming (ECOOP 2019). Editor: Alastair F. Donaldson; Article No. 6; pp. 6:1–6:15 Leibniz International Proceedings in Informatics Schloss Dagstuhl – Leibniz-Zentrum für Informatik, Dagstuhl Publishing, Germany 6:2 Subtyping union types and covariant tuples 44 45 *(x::Number, r::Range) = range(x*first(r),...) 46 *(x::Number, y::Number) = *(promote(x,y)...) 47 48 *(x::T, y::T) where T <: Union{Signed,Unsigned} = mul_int(x,y) 49 The first two methods implement, respectively, multiplicaton of a range by a number and 50 generic numeric multiplication. The third method invokes native multiplication when both 51 arguments are either signed or unsigned integers (but not a mix of the two). Julia uses 52 subtyping to decide which of the methods to call at any specific site. The call 1*(1:4) 53 dispatches to the first, 1*1.1 the second, and 1*1 the third. 54 Julia offers programmers a rich type language to express complex relationships in type 55 signatures. The type language includes nominal primitive types, union types, existential 56 types, covariant tuples, invariant parametric datatypes, and singletons. Intuitively, subtyping 57 between types is based on semantic subtyping: the subtyping relation between types holds 58 when the sets of values they denote are subsets of one another [5]. We write the set of values 59 represented by a type t as t . Under semantic subtyping, the types t1 and t2 are subtypes J K 60 iff t1 ⊆ t2 . From this, we derive a forall-exists intuition for subtyping: for every value J K J K 61 denoted on the left-hand side, there must exist some value on the right-hand side to match 62 it, thereby establishing the subset relation. This simple intuition is, however, complicated to 63 check algorithmically. 64 In this paper, we focus on the interaction of two features: covariant tuples and union 65 types. These two kinds of type are important to Julia’s semantics. Julia does not record 66 return types, so a function’s signature consists solely of the tuple of its argument types. 67 These tuples are covariant, as a function with more specific arguments is preferred to a more 68 generic one. Union types are widely used as shorthand to avoid writing multiple functions 69 with the same body. As a consequence, Julia library developers write many functions with 70 union typed arguments, functions whose relative specificity must be decided using subtyping. 71 To prove the correctness of the subtyping algorithm, we first examine typical approaches 72 in the presence of union types. Based on Vouillon [16], the following is a typical deductive 73 system for subtyping union types: allexist existL existR tuple 0 00 0 00 0 0 ft <: t t <: t t <: t t <: t t1 <: t1 t2 <: t2 0 00 0 00 0 00 0 0 Union{t , t } <: t t <: Union{t , t } t <: Union{t , t } Tuple{t1, t2} <: Tuple{t1, t2} 7574 While this rule system might seem to make intuitive sense, it does not match the semantic 76 intuition for subtyping. For instance, consider the following judgment: 0 00 0 00 77 Tuple{Union{t , t }, t} <: Union{Tuple{t , t}, Tuple{t , t}} 79 Using semantic subtyping, the judgment should hold. The set of values denoted by a 78 80 union Union{t1, t2} is just the union of the set of values denoted by each of its members J K 81 t1 ∪ t2 . A tuple Tuple{t1, t2}’s denotation is the set of tuples of the respective values J K J K 82 {Tuple{v1, v2} | v1 ∈ t1 ∧ v2 ∈ t2 }. Therefore, the left-hand side denotes the values 0 00 0 J0 K 00 00J K 0 83 {Tuple{v , v } | v ∈ t ∪ t ∧ v ∈ t }, while the right-hand side denotes Tuple{t , t} ∪ 00 J K J K J 0K 00 0 0 00 00 J K 84 Tuple{t , t} or equivalently {Tuple{v , v } | v ∈ t ∪ t ∧ v ∈ t }. These sets are the J K J K J K J K 85 same, and therefore subtyping should hold in either direction between the left- and right-hand 86 types. However, we cannot derive this relation from the above rules. According to them, we 0 00 87 must pick either t or t on the right-hand side using existL or existR, respectively, ending 0 00 0 0 00 00 88 up with either Tuple{Union{t , t }, t} <: Tuple{t , t} or Tuple{Union{t , t }, t} <: Tuple{t , t}. 89 In either case, the judgment does not hold. How can this problem be solved? 90 Most prior work addresses this problem by normalization [2, 14, 1], rewriting all types into 91 their disjunctive normal form, as unions of union-free types, before building the derivation. B. Chung, F. Zappa Nardelli, J. Vitek 6:3 92 Now all choices are made at the top level, avoiding the structural entanglements that cause 93 difficulties. The correctness of this rewriting step comes from the semantic denotational 94 model, and the resulting subtyping algorithm can be proved both correct and complete. Other 95 proposals, such as Vouillon [16] and Dunfield [7], do not handle distributivity. Normalization 96 is used by Frisch et al.’s [9], by Pearce’s flow-typing algorithm [13], and by Muehlboeck 97 and Tate in their general framework for union and intersection types [12]. Few alternatives 98 have been proposed, with one example being Damm’s reduction of subtyping to regular tree 99 expression inclusion [6]. 100 However, a normalization-based algorithm has two major drawbacks: it is not space 101 efficient, and other features of Julia render it incorrect.
Recommended publications
  • Homework 2: Reflection and Multiple Dispatch in Smalltalk
    Com S 541 — Programming Languages 1 October 2, 2002 Homework 2: Reflection and Multiple Dispatch in Smalltalk Due: Problems 1 and 2, September 24, 2002; problems 3 and 4, October 8, 2002. This homework can either be done individually or in teams. Its purpose is to familiarize you with Smalltalk’s reflection facilities and to help learn about other issues in OO language design. Don’t hesitate to contact the staff if you are not clear about what to do. In this homework, you will adapt the “multiple dispatch as dispatch on tuples” approach, origi- nated by Leavens and Millstein [1], to Smalltalk. To do this you will have to read their paper and then do the following. 1. (30 points) In a new category, Tuple-Smalltalk, add a class Tuple, which has indexed instance variables. Design this type to provide the necessary methods for working with dispatch on tuples, for example, we’d like to have access to the tuple of classes of the objects in a given tuple. Some of these methods will depend on what’s below. Also design methods so that tuples can be used as a data structure (e.g., to pass multiple arguments and return multiple results). 2. (50 points) In the category, Tuple-Smalltalk, design other classes to hold the behavior that will be declared for tuples. For example, you might want something analogous to a method dictionary and other things found in the class Behavior or ClassDescription. It’s worth studying those classes to see what can be adapted to our purposes.
    [Show full text]
  • TAMING the MERGE OPERATOR a Type-Directed Operational Semantics Approach
    Technical Report, Department of Computer Science, the University of Hong Kong, Jan 2021. 1 TAMING THE MERGE OPERATOR A Type-directed Operational Semantics Approach XUEJING HUANG JINXU ZHAO BRUNO C. D. S. OLIVEIRA The University of Hong Kong (e-mail: fxjhuang, jxzhao, [email protected]) Abstract Calculi with disjoint intersection types support a symmetric merge operator with subtyping. The merge operator generalizes record concatenation to any type, enabling expressive forms of object composition, and simple solutions to hard modularity problems. Unfortunately, recent calculi with disjoint intersection types and the merge operator lack a (direct) operational semantics with expected properties such as determinism and subject reduction, and only account for terminating programs. This paper proposes a type-directed operational semantics (TDOS) for calculi with intersection types and a merge operator. We study two variants of calculi in the literature. The first calculus, called li, is a variant of a calculus presented by Oliveira et al. (2016) and closely related to another calculus by Dunfield (2014). Although Dunfield proposes a direct small-step semantics for her calcu- lus, her semantics lacks both determinism and subject reduction. Using our TDOS we obtain a direct + semantics for li that has both properties. The second calculus, called li , employs the well-known + subtyping relation of Barendregt, Coppo and Dezani-Ciancaglini (BCD). Therefore, li extends the more basic subtyping relation of li, and also adds support for record types and nested composition (which enables recursive composition of merged components). To fully obtain determinism, both li + and li employ a disjointness restriction proposed in the original li calculus.
    [Show full text]
  • Julia: a Fresh Approach to Numerical Computing
    RSDG @ UCL Julia: A Fresh Approach to Numerical Computing Mosè Giordano @giordano [email protected] Knowledge Quarter Codes Tech Social October 16, 2019 Julia’s Facts v1.0.0 released in 2018 at UCL • Development started in 2009 at MIT, first • public release in 2012 Julia co-creators won the 2019 James H. • Wilkinson Prize for Numerical Software Julia adoption is growing rapidly in • numerical optimisation, differential equations, machine learning, differentiable programming It is used and taught in several universities • (https://julialang.org/teaching/) Mosè Giordano (RSDG @ UCL) Julia: A Fresh Approach to Numerical Computing October 16, 2019 2 / 29 Julia on Nature Nature 572, 141-142 (2019). doi: 10.1038/d41586-019-02310-3 Mosè Giordano (RSDG @ UCL) Julia: A Fresh Approach to Numerical Computing October 16, 2019 3 / 29 Solving the Two-Language Problem: Julia Multiple dispatch • Dynamic type system • Good performance, approaching that of statically-compiled languages • JIT-compiled scripts • User-defined types are as fast and compact as built-ins • Lisp-like macros and other metaprogramming facilities • No need to vectorise: for loops are fast • Garbage collection: no manual memory management • Interactive shell (REPL) for exploratory work • Call C and Fortran functions directly: no wrappers or special APIs • Call Python functions: use the PyCall package • Designed for parallelism and distributed computation • Mosè Giordano (RSDG @ UCL) Julia: A Fresh Approach to Numerical Computing October 16, 2019 4 / 29 Multiple Dispatch using DifferentialEquations
    [Show full text]
  • Concepts in Programming Languages Practicalities
    Concepts in Programming Languages Practicalities I Course web page: Alan Mycroft1 www.cl.cam.ac.uk/teaching/1617/ConceptsPL/ with lecture slides, exercise sheet and reading material. These slides play two roles – both “lecture notes" and “presentation material”; not every slide will be lectured in Computer Laboratory detail. University of Cambridge I There are various code examples (particularly for 2016–2017 (Easter Term) JavaScript and Java applets) on the ‘materials’ tab of the course web page. I One exam question. www.cl.cam.ac.uk/teaching/1617/ConceptsPL/ I The syllabus and course has changed somewhat from that of 2015/16. I would be grateful for comments on any remaining ‘rough edges’, and for views on material which is either over- or under-represented. 1Acknowledgement: various slides are based on Marcelo Fiore’s 2013/14 course. Alan Mycroft Concepts in Programming Languages 1 / 237 Alan Mycroft Concepts in Programming Languages 2 / 237 Main books Context: so many programming languages I J. C. Mitchell. Concepts in programming languages. Cambridge University Press, 2003. Peter J. Landin: “The Next 700 Programming Languages”, I T.W. Pratt and M. V.Zelkowitz. Programming Languages: CACM (published in 1966!). Design and implementation (3RD EDITION). Some programming-language ‘family trees’ (too big for slide): Prentice Hall, 1999. http://www.oreilly.com/go/languageposter http://www.levenez.com/lang/ ? M. L. Scott. Programming language pragmatics http://rigaux.org/language-study/diagram.html (4TH EDITION). http://www.rackspace.com/blog/ Elsevier, 2016. infographic-evolution-of-computer-languages/ I R. Harper. Practical Foundations for Programming Plan of this course: pick out interesting programming-language Languages.
    [Show full text]
  • Characteristics of Mathematical Modeling Languages That
    www.nature.com/npjsba ARTICLE OPEN Characteristics of mathematical modeling languages that facilitate model reuse in systems biology: a software engineering perspective ✉ Christopher Schölzel 1 , Valeria Blesius1, Gernot Ernst2,3 and Andreas Dominik 1 Reuse of mathematical models becomes increasingly important in systems biology as research moves toward large, multi-scale models composed of heterogeneous subcomponents. Currently, many models are not easily reusable due to inflexible or confusing code, inappropriate languages, or insufficient documentation. Best practice suggestions rarely cover such low-level design aspects. This gap could be filled by software engineering, which addresses those same issues for software reuse. We show that languages can facilitate reusability by being modular, human-readable, hybrid (i.e., supporting multiple formalisms), open, declarative, and by supporting the graphical representation of models. Modelers should not only use such a language, but be aware of the features that make it desirable and know how to apply them effectively. For this reason, we compare existing suitable languages in detail and demonstrate their benefits for a modular model of the human cardiac conduction system written in Modelica. npj Systems Biology and Applications (2021) 7:27 ; https://doi.org/10.1038/s41540-021-00182-w 1234567890():,; INTRODUCTION descriptions of experiment setup or design choices6–8. A recent As the understanding of biological systems grows, it becomes study by curators of the BioModels database showed that only 8 more and more apparent that their behavior cannot be reliably 51% of 455 published models were directly reproducible .Inan 9 predicted without the help of mathematical models. In the past, extreme case, Topalidou et al.
    [Show full text]
  • Strategic Location and Dispatch Management of Assets in a Military Medical Evacuation Enterprise Phillip R
    Air Force Institute of Technology AFIT Scholar Theses and Dissertations Student Graduate Works 6-19-2019 Strategic Location and Dispatch Management of Assets in a Military Medical Evacuation Enterprise Phillip R. Jenkins Follow this and additional works at: https://scholar.afit.edu/etd Part of the Operations and Supply Chain Management Commons Recommended Citation Jenkins, Phillip R., "Strategic Location and Dispatch Management of Assets in a Military Medical Evacuation Enterprise" (2019). Theses and Dissertations. 2292. https://scholar.afit.edu/etd/2292 This Dissertation is brought to you for free and open access by the Student Graduate Works at AFIT Scholar. It has been accepted for inclusion in Theses and Dissertations by an authorized administrator of AFIT Scholar. For more information, please contact [email protected]. Strategic Location and Dispatch Management of Assets in a Military Medical Evacuation Enterprise DISSERTATION Phillip R. Jenkins, Capt, USAF AFIT-ENS-DS-19-J-037 DEPARTMENT OF THE AIR FORCE AIR UNIVERSITY AIR FORCE INSTITUTE OF TECHNOLOGY Wright-Patterson Air Force Base, Ohio DISTRIBUTION STATEMENT A APPROVED FOR PUBLIC RELEASE; DISTRIBUTION UNLIMITED. The views expressed in this document are those of the author and do not reflect the official policy or position of the United States Air Force, the United States Department of Defense or the United States Government. This material is declared a work of the U.S. Government and is not subject to copyright protection in the United States. AFIT-ENS-DS-19-J-037 STRATEGIC LOCATION AND DISPATCH MANAGEMENT OF ASSETS IN A MILITARY MEDICAL EVACUATION ENTERPRISE DISSERTATION Presented to the Faculty Graduate School of Engineering and Management Air Force Institute of Technology Air University Air Education and Training Command in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy Phillip R.
    [Show full text]
  • First-Class Dynamic Types (2019)
    First-Class Dynamic Types∗ Michael Homer Timothy Jones James Noble School of Engineering Montoux School of Engineering and Computer Science New York, USA and Computer Science Victoria University of Wellington [email protected] Victoria University of Wellington New Zealand New Zealand [email protected] [email protected] Abstract 1 Introduction Since LISP, dynamic languages have supported dynamically- Most dynamically-typed languages do not provide much sup- checked type annotations. Even in dynamic languages, these port for programmers incorporating type checks in their annotations are typically static: tests are restricted to check- programs. Object-oriented languages have dynamic dispatch ing low-level features of objects and values, such as primi- and often explicit “instance of” reflective operations, grad- tive types or membership of an explicit programmer-defined ual typing provides mixed-mode enforcement of a single class. static type system, and functional languages often include We propose much more dynamic types for dynamic lan- pattern-matching partial functions, all of which are relatively guages — first-class objects that programmers can custom- limited at one end of the spectrum. At the other end, lan- ise, that can be composed with other types and depend on guages like Racket support higher-order dynamic contract computed values — and to use these first-class type-like val- systems, wrapping objects to verify contracts lazily, and with ues as types. In this way programs can define their own con- concomitant power, complexity, and overheads [10, 51]. ceptual models of types, extending both the kinds of tests Programmers may wish for a greater level of run-time programs can make via types, and the guarantees those tests checking than provided by the language, or merely different can provide.
    [Show full text]
  • Multiple Dispatch As Dispatch on Tuples Gary T
    Computer Science Technical Reports Computer Science 7-1998 Multiple Dispatch as Dispatch on Tuples Gary T. Leavens Iowa State University Todd Millstein Iowa State University Follow this and additional works at: http://lib.dr.iastate.edu/cs_techreports Part of the Systems Architecture Commons, and the Theory and Algorithms Commons Recommended Citation Leavens, Gary T. and Millstein, Todd, "Multiple Dispatch as Dispatch on Tuples" (1998). Computer Science Technical Reports. 131. http://lib.dr.iastate.edu/cs_techreports/131 This Article is brought to you for free and open access by the Computer Science at Iowa State University Digital Repository. It has been accepted for inclusion in Computer Science Technical Reports by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Multiple Dispatch as Dispatch on Tuples Abstract Many popular object-oriented programming languages, such as C++, Smalltalk-80, Java, and Eiffel, do not support multiple dispatch. Yet without multiple dispatch, programmers find it difficult to express binary methods and design patterns such as the ``visitor'' pattern. We describe a new, simple, and orthogonal way to add multimethods to single-dispatch object-oriented languages, without affecting existing code. The new mechanism also clarifies many differences between single and multiple dispatch. Keywords Multimethods, generic functions, object-oriented programming languages, single dispatch, multiple dispatch, tuples, product types, encapsulation,
    [Show full text]
  • Array Operators Using Multiple Dispatch: a Design Methodology for Array Implementations in Dynamic Languages
    Array Operators Using Multiple Dispatch: A design methodology for array implementations in dynamic languages The MIT Faculty has made this article openly available. Please share how this access benefits you. Your story matters. Citation Jeff Bezanson, Jiahao Chen, Stefan Karpinski, Viral Shah, and Alan Edelman. 2014. Array Operators Using Multiple Dispatch: A design methodology for array implementations in dynamic languages. In Proceedings of ACM SIGPLAN International Workshop on Libraries, Languages, and Compilers for Array Programming (ARRAY '14). ACM, New York, NY, USA, 56-61, 6 pages. As Published http://dx.doi.org/10.1145/2627373.2627383 Publisher Association for Computing Machinery (ACM) Version Author's final manuscript Citable link http://hdl.handle.net/1721.1/92858 Terms of Use Creative Commons Attribution-Noncommercial-Share Alike Detailed Terms http://creativecommons.org/licenses/by-nc-sa/4.0/ Array Operators Using Multiple Dispatch Array Operators Using Multiple Dispatch A design methodology for array implementations in dynamic languages Jeff Bezanson Jiahao Chen Stefan Karpinski Viral Shah Alan Edelman MIT Computer Science and Artificial Intelligence Laboratory [email protected], [email protected], [email protected], [email protected], [email protected] Abstract ficient, such as loop fusion for array traversals and common subex- Arrays are such a rich and fundamental data type that they tend to pression elimination for indexing operations [3, 24]. Many lan- be built into a language, either in the compiler or in a large low- guage implementations therefore choose to build array semantics level library. Defining this functionality at the user level instead into compilers. provides greater flexibility for application domains not envisioned Only a few of the languages that support n-arrays, however, by the language designer.
    [Show full text]
  • Function Programming in Python
    Functional Programming in Python David Mertz Additional Resources 4 Easy Ways to Learn More and Stay Current Programming Newsletter Get programming related news and content delivered weekly to your inbox. oreilly.com/programming/newsletter Free Webcast Series Learn about popular programming topics from experts live, online. webcasts.oreilly.com O’Reilly Radar Read more insight and analysis about emerging technologies. radar.oreilly.com Conferences Immerse yourself in learning at an upcoming O’Reilly conference. conferences.oreilly.com ©2015 O’Reilly Media, Inc. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. #15305 Functional Programming in Python David Mertz Functional Programming in Python by David Mertz Copyright © 2015 O’Reilly Media, Inc. All rights reserved. Attribution-ShareAlike 4.0 International (CC BY-SA 4.0). See: http://creativecommons.org/licenses/by-sa/4.0/ Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://safaribooksonline.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or [email protected]. Editor: Meghan Blanchette Interior Designer: David Futato Production Editor: Shiny Kalapurakkel Cover Designer: Karen Montgomery Proofreader: Charles Roumeliotis May 2015: First Edition Revision History for the First Edition 2015-05-27: First Release The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Functional Pro‐ gramming in Python, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc.
    [Show full text]
  • Perl 6 Introduction
    Perl 6 Introduction Naoum Hankache [email protected] Table of Contents 1. Introduction 1.1. What is Perl 6 1.2. Jargon 1.3. Installing Perl 6 1.4. Running Perl 6 code 1.5. Editors 1.6. Hello World! 1.7. Syntax overview 2. Operators 3. Variables 3.1. Scalars 3.2. Arrays 3.3. Hashes 3.4. Types 3.5. Introspection 3.6. Scoping 3.7. Assignment vs. Binding 4. Functions and mutators 5. Loops and conditions 5.1. if 5.2. unless 5.3. with 5.4. for 5.5. given 5.6. loop 6. I/O 6.1. Basic I/O using the Terminal 6.2. Running Shell Commands 6.3. File I/O 6.4. Working with files and directories 7. Subroutines 7.1. Definition 7.2. Signature 7.3. Multiple dispatch 7.4. Default and Optional Arguments 8. Functional Programming 8.1. Functions are first-class citizens 8.2. Closures 8.3. Anonymous functions 8.4. Chaining 8.5. Feed Operator 8.6. Hyper operator 8.7. Junctions 8.8. Lazy Lists 9. Classes & Objects 9.1. Introduction 9.2. Encapsulation 9.3. Named vs. Positional Arguments 9.4. Methods 9.5. Class Attributes 9.6. Access Type 9.7. Inheritance 9.8. Multiple Inheritance 9.9. Roles 9.10. Introspection 10. Exception Handling 10.1. Catching Exceptions 10.2. Throwing Exceptions 11. Regular Expressions 11.1. Regex definition 11.2. Matching characters 11.3. Matching categories of characters 11.4. Unicode properties 11.5. Wildcards 11.6. Quantifiers 11.7. Match Results 11.8.
    [Show full text]
  • Multimethods
    11-A1568 01/23/2001 12:39 PM Page 263 11 Multimethods This chapter defines, discusses, and implements multimethods in the context of Cϩϩ . The Cϩϩ virtual function mechanism allows dispatching a call depending on the dynamic type of one object. The multimethods feature allows dispatching a function call depending on the types of multiple objects. A universally good implementation requires language support, which is the route that languages such as CLOS, ML, Haskell, and Dylan have taken. Cϩϩ lacks such support, so its emulation is left to library writers. This chapter discusses some typical solutions and some generic implementations of each. The solutions feature various trade-offs in terms of speed, flexibility, and dependency management. To describe the technique of dispatching a function call depending on mul- tiple objects, this book uses the terms multimethod (borrowed from CLOS) and multiple dis- patch. A particularization of multiple dispatch for two objects is known as double dispatch. Implementing multimethods is a problem as fascinating as dreaded, one that has stolen lots of hours of good, healthy sleep from designers and programmers.1 The topics of this chapter include • Defining multimethods • Identifying situations in which the need for multiobject polymorphism appears • Discussing and implementing three double dispatchers that foster different trade-offs • Enhancing double-dispatch engines After reading this chapter, you will have a firm grasp of the typical situations for which multimethods are the way to go. In addition, you will be able to use and extend several ro- bust generic components implementing multimethods, provided by Loki. This chapter limits discussion to multimethods for two objects (double dispatch).
    [Show full text]