DOCSLIB.ORG

Dynamic Dispatch in Object-Oriented Languages

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Dynamic Dispatch in Object-Oriented Languages Dynamic Dispatch in Ob ject-Oriented Languages y Scott Milton and Heinz W. Schmidt TR-CS-94-02 [email protected], [email protected] January 1994 Abstract Dynamic binding in ob ject-oriented languages is p erhaps the most imp ortant semantic asp ect of these languages. At the same time it can contribute to ineciency and lackof robustness b ecause it incurs lo okup overheads on function calls and hinders the compiler determining the exact typ e of ob jects held in variables or returned by functions. This may, for instance, preclude inlining of small functions or attribute o set computation at compile time. Yet attribute accesses are the most frequently executed op erations. As a result, to regain lost p erformance, OO programmers are tempted to break the encapsulation of classes or want explicit control over dynamic dispatch, trading o extensibility. In the implementation of parallel ob ject-oriented languages the additional complication arises that ob ject accesses may require more exp ensive remote memory accesses. Lo okup at the call may b e inappropriate if the co de has to b e executed on a di erent pro cessor and there p erhaps has a di erent address. This pap er summarizes dispatching as addressed in several mo dern ob ject-oriented languages. We then describ e and b enchmark fast and exible dispatchschemes that we are currently implementing on SPARC based workstations and multi-pro cessors. These involve elements of C++ virtual function tables and Ei el's and Sather's ability to rede ne abstract functions as attributes. Initial b enchmarks seem to promise improved eciency on a range of mo dern RISC based architectures. Categories and Sub ject Descriptors: D.1.1 [Programming Techniques]: ob ject-oriented programming; D.3.2 [Programming languages]: Language Classi cation { object-oriented languages,C++, Ei el, Sather; D.3.3 [Programming languages]: Language Constructs { dynamic binding; D.3.4 [Programming languages]: Pro cessors { compilers, optimization; E.1 [Data]: Data Structures { tables ; General Terms: Algorithms, Design, Languages. Additional Keywords and Phrases: b enchmarks, dynamic dispatch, eciency, ob ject-oriented runtime system, multiple inheritance. Department of Computer Science, The Australian National University, Canb erra y CSIRO { Division of Information Technology, Canb erra 1 1 Intro duction Dynamic binding of function names to function de nitions or co de entry p oints is one of the central features of ob ject-oriented languages. It contributes to exibility and extensibility b ecause it allows new co de to b e called from unaltered old co de by passing instances of new typ es to old functions or assigning them to old variables. Conceptually, the ob jects themselves resp ond to calls. Function binding is at their discretion in ob ject-based languages or at the discretion of their classes in class-based languages. We call functions and attributes collectively features.Features are abstract if they are p olymorphic, i.e., rede nable for di erent typ es of ob jects. In some languages all features are abstract, in others one has to distinguish them upfront, i.e., b efore any rede nition is p ermitted or dynamic dispatch is supp orted. For instance, in C++ one uses the virtual keyword [27] to this end, or in CLOS, one declares functions as generic [1, 25,10]. The mechanism implementing dynamic binding is called dynamic dispatch. Typically it uses runtime typ e information to lo okup, or bind to, the prop er function. Systems like the Lisp-machine op erating system with ab out 2000 classes or Smalltalk systems with many hundreds of classes rely on this mechanism to make prototyping and incremental compilation fast, and systems in op eration robust in the presence of adho c extensions. There is a tension b etween dynamic dispatch and static typing. The exibility resulting from dynamic dispatch go es directly against the safety and increased compile time knowledge of data typ es needed for early error detection and for the b est optimisation. There are inherent tradeo s in howmuchchecking is p ossible at compile time versus howmuchmust b e done at runtime to guarantee that, for instance, optimiser assumptions ab out typing are preserved during execution. The dynamic lo okup is a ma jor obstacle to optimisation from two di erent viewp oints: rst, the lo okup time has to b e paid in addition to the function call; secondly, since di erent functions maybeinvoked by the same call in the course of execution, small functions can no longer b e inlined, and attribute o sets cannot b e computed statically,in general. Yet attribute accesses are the most frequently executed op erations. The inlinin g problem can also cause intra-pro cedural optimisations to b e deferred that would only b e p ossible after inlinin g in the context of an expanded function b o dy. This is particularly relevant with lo ops in OO programs when a generic iteration metho d is encap- sulated with a class and a caller drives these iterations in a lo op outside the corresp onding class. For eciency reasons, OO programmers are then tempted to break the encapsulation and/or demand more explicit control over dispatch while giving away extensibility. Eciency is critical for the wide use of any language. We are particularly interested in ecient dispatch mechanisms for our exp erimental high-p erformance Sather [20,21]. The implementation of ecient dynamic dispatch has b een the sub ject of several pap ers. For instance Rose [19] compares various low-level interrupt-based dispatching on sto ck hard- ware that makes single dispatch as fast as function calls at the cost of p ortability. Some implementations such as CLOS [11] and Sather [17, 18, 22] use hashing while others such as C++ and Ei el [15] use lo okup tables. CLOS calls a generic function which encapsulates the lo okup, while most other languages generate sp ecial call instructions. Sather and C++ [27] currently employvery di erent dynamic dispatching mechanisms. C++ ob jects have em- b edded p ointers to function lo okup tables to allow shared co de inherited functions to nd p ossibly rede ned functions in sub classes. Sather uses ob ject typ e tags and function keys to hash for function p ointers. 2 On top of the dispatching mechanisms various optimisations are used. A foremost goal is to avoid dynamic dispatch wherever p ossible. Languages likeC++ and Sather restrict proto- typing exibility to help the programmer and compiler control the asso ciated cost of dynamic dispatch. In C++ one distinguishes abstract functions with several di erent implementations by the virtual keyword when de ning them the rst time. Sather distinguishes dispatched calls according to the typ e of ob jects: the declaration x: A, allows x to hold only ob jects of exactly typ e A, while x: $A can hold ob jects of any subtyp e. In the former case calls to the ob ject can b e resolved at compile time. In addition, some languages such as CLOS, Self [4] and Sather try to o set the cost of dispatching by other optimisation, to o, including so-called customisation and function pointer caching. Function p ointer caches allowcheap lo okups if the function was recently lo oked-up for the same typ e of ob ject. Customisation duplicates and customises inherited co de for each sub class. With cus- tomisation, calls to self can b e resolved statically. Ful l customisation, which customises all functions in a given class, has another advantage: exclusively customised co de is going to ac- cess instances of this class. The class can therefore cho ose the layout of instances to improve compaction and alignment which can make an order of magnitude sp eed di erence on RISC architectures such as the DIGITAL Alpha. Furthermore, all attribute accesses to self can b e hardwired in the co de. The downside of full customisation is of course increased co de size and longer recompilation times, as changes in inherited functions may a ect several sub classes. In this pap er we brie y review di erent OO dispatching schemes, particularly fo cusing on C++ and Sather eciency needs, and complexity resulting from multiple inheritance. We rep ort initial b enchmarking results, and prop ose a new ecienthybrid scheme extending C++ function tables. We discuss this in the context of the Sather language but elements of the scheme can b e used with C++, Ei el or other MI languages. 2 Dynamic Dispatch: Concepts and Implementations In general terms, the dispatch problem can b e characterized as follows: Given a class name c andafeature name f , determine the actual featurelocation function pointer, attribute o set p = Locc; f : A naive implementation enco des Loc by a table of the size C F leading to a fast constant time lo okup, where C is the numb er of class names and F the numb er of feature names. Each column in this table can b e viewed as representing an abstract feature f that can lo okup a function p ointer or attribute o set given a class index. Dually, eachrow represents a function table for the corresp onding class c. Unfortunately, for large OO co des these tables are extremely sparse. The space requirements are unacceptable and the tables are not extensible. When new classes or features are added, a large table has to b e reorganised, which is unacceptable with incremental compilation. Various dispatchschemes therefore try to take advantage of the most common incremental compilation, viz., adding and compiling individual classes without requiring recomputation of tables for already compiled classes.
Load more

Recommended publications
  • MANNING Greenwich (74° W
    Object Oriented Perl Object Oriented Perl DAMIAN CONWAY MANNING Greenwich (74° w. long.) For electronic browsing and ordering of this and other Manning books, visit http://www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact: Special Sales Department Manning Publications Co. 32 Lafayette Place Fax: (203) 661-9018 Greenwich, CT 06830 email: [email protected] ©2000 by Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Library of Congress Cataloging-in-Publication Data Conway, Damian, 1964- Object oriented Perl / Damian Conway. p. cm. includes bibliographical references. ISBN 1-884777-79-1 (alk. paper) 1. Object-oriented programming (Computer science) 2. Perl (Computer program language) I. Title. QA76.64.C639 1999 005.13'3--dc21 99-27793 CIP Manning Publications Co. Copyeditor: Adrianne Harun 32 Lafayette
    [Show full text]
  • Introduction Code Reuse
    The Sather Language: Efficient, Interactive, Object-Oriented Programming Stephen Omohundro Dr. Dobbs Journal Introduction Sather is an object oriented language which aims to be simple, efficient, interactive, safe, and non-proprietary. One way of placing it in the "space of languages" is to say that it aims to be as efficient as C, C++, or Fortran, as elegant and safe as Eiffel or CLU, and to support interactive programming and higher-order functions as well as Common Lisp, Scheme, or Smalltalk. Sather has parameterized classes, object-oriented dispatch, statically-checked strong typing, separate implementation and type inheritance, multiple inheritance, garbage collection, iteration abstraction, higher-order routines and iters, exception handling, constructors for arbitrary data structures, and assertions, preconditions, postconditions, and class invariants. This article describes the first few of these features. The development environment integrates an interpreter, a debugger, and a compiler. Sather programs can be compiled into portable C code and can efficiently link with C object files. Sather has a very unrestrictive license which allows its use in proprietary projects but encourages contribution to the public library. The original 0.2 version of the Sather compiler and tools was made available in June 1991. This article describes version 1.0. By the time the article appears, the combined 1.0 compiler/interpreter/debugger should be available on "ftp.icsi.berkeley.edu" and the newsgroup "comp.lang.sather" should be activated for discussion. Code Reuse The primary benefit promised by object-oriented languages is reuse of code. Sather programs consist of collections of modules called "classes" which encapsulate well-defined abstractions.
    [Show full text]
  • Comp 411 Principles of Programming Languages Lecture 19 Semantics of OO Languages
    Comp 411 Principles of Programming Languages Lecture 19 Semantics of OO Languages Corky Cartwright Mar 10-19, 2021 Overview I • In OO languages, OO data values (except for designated non-OO types) are special records [structures] (finite mappings from names to values). In OO parlance, the components of record are called members. • Some members of an object may be functions called methods. Methods take this (the object in question) as an implicit parameter. Some OO languages like Java also support static methods that do not depend on this; these methods have no implicit parameters. In efficient OO language implementations, method members are shared since they are the same for all instances of a class, but this sharing is an optimization in statically typed OO languages since the collection of methods in a class is immutable during program evaluation (computation). • A method (instance method in Java) can only be invoked on an object (the receiver, an implicit parameter). Additional parameters are optional, depending on whether the method expects them. This invocation process is called dynamic dispatch because the executed code is literally extracted from the object: the code invoked at a call site depends on the value of the receiver, which can change with each execution of the call. • A language with objects is OO if it supports dynamic dispatch (discussed in more detail in Overview II & III) and inheritance, an explicit taxonomy for classifying objects based on their members and class names where superclass/parent methods are inherited unless overridden. • In single inheritance, this taxonomy forms a tree; • In multiple inheritance, it forms a rooted DAG (directed acyclic graph) where the root class is the universal class (Object in Java).
    [Show full text]
  • Dynamic Dispatch
    CS 3110 Lecture 24: Dynamic Dispatch Prof. Clarkson Spring 2015 Today’s music: "Te Core" by Eric Clapton Review Current topic: functional vs. object-oriented programming Today: • Continue encoding objects in OCaml • Te core of OOP – dynamic dispatch – sigma calculus Review: key features of OOP 1. Encapsulation 2. Subtyping 3. Inheritance 4. Dynamic dispatch Review: Counters class Counter {! protected int x = 0;! public int get() { return x; }! public void inc() { x++; }! }! Review: Objects • Type of object is record of functions !type counter = {! !get : unit -> int;! !inc : unit -> unit;! !} • Let-binding hides internal state (with closure) !let x = ref 0 in {! !get = (fun () -> !x);! !inc = (fun () -> x := !x+1);! !}! Review: Classes • Representation type for internal state: !type counter_rep = {! !!x : int ref;! !}! • Class is a function from representation type to object: !let counter_class (r:counter_rep) = {! !!get = (fun () -> !(r.x));! !!inc = (fun () -> (r.x := !(r.x) + 1));! !}! • Constructor uses class function to make a new object: !let new_counter () =! !!let r = {x = ref 0} in! ! !counter_class r !! Review: Inheritance • Subclass creates an object of the superclass with the same internal state as its own – Bind resulting parent object to super • Subclass creates a new object with same internal state • Subclass copies (inherits) any implementations it wants from superclass 4. DYNAMIC DISPATCH This class SetCounter {! protected int x = 0;! public int get() { return x; }! public void set(int i) { x = i; }! public void inc()
    [Show full text]
  • CLOS, Eiffel, and Sather: a Comparison
    CLOS, Eiffel, and Sather: A Comparison Heinz W. Schmidt-, Stephen M. Omohundrot " September, 1991 li ____________T_R_._91_-0_47____________~ INTERNATIONAL COMPUTER SCIENCE INSTITUTE 1947 Center Street, Suite 600 Berkeley, California 94704-1105 CLOS, Eiffel, and Sather: A Comparison Heinz W. Schmidt-, Stephen M. Omohundrot September, 1991 Abstract The Common Lisp Object System defines a powerful and flexible type system that builds on more than fifteen years of experience with object-oriented programming. Most current implementations include a comfortable suite of Lisp support tools in­ cluding an Emacs Lisp editor, an interpreter, an incremental compiler, a debugger, and an inspector that together promote rapid prototyping and design. What else might one want from a system? We argue that static typing yields earlier error detec­ tion, greater robustness, and higher efficiency and that greater simplicity and more orthogonality in the language constructs leads to a shorter learning curve and more in­ tuitive programming. These elements can be found in Eiffel and a new object-oriented language, Sather, that we are developing at leS!. Language simplicity and static typ­ ing are not for free,·though. Programmers have to pay with loss of polymorphism and flexibility in prototyping. We give a short comparison of CLOS, Eiffel and Sather, addressing both language and environment issues. The different approaches taken by the languages described in this paper have evolved to fulfill different needs. While we have only touched on the essential differ­ ences, we hope that this discussion will be helpful in understanding the advantages and disadvantages of each language. -ICSI, on leave from: Inst. f. Systemtechnik, GMD, Germany tICSI 1 Introduction Common Lisp [25] was developed to consolidate the best ideas from a long line of Lisp systems and has become an important standard.
    [Show full text]
  • Iterable Abstract Pattern Matching for Java
    JMatch: Iterable Abstract Pattern Matching for Java Jed Liu and Andrew C. Myers Computer Science Department Cornell University, Ithaca, New York Abstract. The JMatch language extends Java with iterable abstract pattern match- ing, pattern matching that is compatible with the data abstraction features of Java and makes iteration abstractions convenient. JMatch has ML-style deep pattern matching, but patterns can be abstract; they are not tied to algebraic data con- structors. A single JMatch method may be used in several modes; modes may share a single implementation as a boolean formula. Modal abstraction simplifies specification and implementation of abstract data types. This paper describes the JMatch language and its implementation. 1 Introduction Object-oriented languages have become a dominant programming paradigm, yet they still lack features considered useful in other languages. Functional languages offer expressive pattern matching. Logic programming languages provide powerful mech- anisms for iteration and backtracking. However, these useful features interact poorly with the data abstraction mechanisms central to object-oriented languages. Thus, ex- pressing some computations is awkward in object-oriented languages. In this paper we present the design and implementation of JMatch, a new object- oriented language that extends Java [GJS96] with support for iterable abstract pattern matching—a mechanism for pattern matching that is compatible with the data abstrac- tion features of Java and that makes iteration abstractions more convenient.
    [Show full text]
  • Specialising Dynamic Techniques for Implementing the Ruby Programming Language
    SPECIALISING DYNAMIC TECHNIQUES FOR IMPLEMENTING THE RUBY PROGRAMMING LANGUAGE A thesis submitted to the University of Manchester for the degree of Doctor of Philosophy in the Faculty of Engineering and Physical Sciences 2015 By Chris Seaton School of Computer Science This published copy of the thesis contains a couple of minor typographical corrections from the version deposited in the University of Manchester Library. [email protected] chrisseaton.com/phd 2 Contents List of Listings7 List of Tables9 List of Figures 11 Abstract 15 Declaration 17 Copyright 19 Acknowledgements 21 1 Introduction 23 1.1 Dynamic Programming Languages.................. 23 1.2 Idiomatic Ruby............................ 25 1.3 Research Questions.......................... 27 1.4 Implementation Work......................... 27 1.5 Contributions............................. 28 1.6 Publications.............................. 29 1.7 Thesis Structure............................ 31 2 Characteristics of Dynamic Languages 35 2.1 Ruby.................................. 35 2.2 Ruby on Rails............................. 36 2.3 Case Study: Idiomatic Ruby..................... 37 2.4 Summary............................... 49 3 3 Implementation of Dynamic Languages 51 3.1 Foundational Techniques....................... 51 3.2 Applied Techniques.......................... 59 3.3 Implementations of Ruby....................... 65 3.4 Parallelism and Concurrency..................... 72 3.5 Summary............................... 73 4 Evaluation Methodology 75 4.1 Evaluation Philosophy
    [Show full text]
  • Subclassing and Dynamic Dispatch
    Subclassing and Dynamic Dispatch 6.170 Lecture 3 This lecture is about dynamic dispatch: how a call o.m() may actually invoke the code of different methods, all with the same name m, depending on the runtime type of the receiver object o. To explain how this happens, we show how one class can be defined as a subclass of another, and can override some of its methods. This is called subclassing or inheritance, and it is a central feature of object oriented languages. At the same time, it’s arguably a rather dangerous and overrused feature, for reasons that we’ll discuss later when we look at subtyping. The notion of dynamic dispatch is broader than the notion of inheritance. You can write a Java program with no inheritance in which dynamic dispatch still occurs. This is because Java has built- in support for specifications. You can declare an object to satisfy a kind of partial specification called an interface, and you can provide many implementations of the same interface. This is actually a more important and fundamental notion than subclassing, and it will be discussed in our lecture on specification. 1 Bank Transaction Code Here is the code for a class representing a bank account: class Account { String name; Vector transv; int balance; Account (String n) { transv = new Vector (); balance = 0; name = n; } boolean checkTrans (Trans t) { return (balance + t.amount >= 0); } void post (Trans t) { transv.add (t); balance += t.amount; } } and a class representing a transaction: class Trans { int amount; 1 Date date; ... } 2 Extending a Class by Inheritance Suppose we want to implement a new kind of account that allows overdrafts.
    [Show full text]
  • Topic 9: Type Checking • Readings: • Chapter 13.5, 13.6 and 13.7
    Recommended Exercises and Readings • From Haskell: The craft of functional programming (3rd Ed.) • Exercises: • 13.17, 13.18, 13.19, 13.20, 13.21, 13.22 Topic 9: Type Checking • Readings: • Chapter 13.5, 13.6 and 13.7 1 2 Type systems Static vs. Dynamic Typing • There are (at least) three different ways that we can compare type • Static typing systems • The type of a variable is known at compile time • Static vs. dynamic typing • It is explicitly stated by the programmer… • Strong vs. weak typing • Or it can be inferred from context • Explicit vs. implicit typing • Type checking can be performed without running the program • Used by Haskell • Also used by C, C++, C#, Java, Fortran, Pascal, … 3 4 Static vs. Dynamic Typing Static vs. Dynamic Typing • Dynamic typing • Static vs. Dynamic typing is a question of timing… • The type of a variable is not known until the program is running • When is type checking performed? • Typically determined from the value that is actually stored in it • At compile time (before the program runs)? Static • Program can crash at runtime due to incorrect types • As the program is running? Dynamic • Permits downcasting, dynamic dispatch, reflection, … • Used by Python, Javascript, PHP, Lisp, Ruby, … 5 6 Static vs. Dynamic Typing Static vs. Dynamic Typing • Some languages do a mixture of both of static and dynamic typing • Advantages of static typing • Most type checking in Java is performed at compile time… • … but downcasting is permitted, and can’t be verified at compile time • Generated code includes a runtime type check • A ClassCastException is thrown if the downcast wasn’t valid • Advantages of dynamic typing • Most type checking in C++ is performed at compile time.
    [Show full text]
  • Concepts in Programming Languages
    Concepts in Programming Languages Alan Mycrofta Computer Laboratory University of Cambridge 2014–2015 (Easter Term) http://www.cl.cam.ac.uk/teaching/1415/ConceptsPL/ aNotes largely due to Marcelo Fiore—but errors are my responsibility. 1 Practicalities Course web page: www.cl.cam.ac.uk/teaching/1415/ConceptsPL/ with lecture slides, exercise sheet, and reading material. One exam question. 2 Main books J. C. Mitchell. Concepts in programming languages. Cambridge University Press, 2003. T.W. Pratt and M. V.Zelkowitz. Programming Languages: Design and implementation (3RD EDITION). Prentice Hall, 1999. ⋆ M. L. Scott. Programming language pragmatics (2ND EDITION). Elsevier, 2006. R. Harper. Practical Foundations for Programming Languages. Cambridge University Press, 2013. 3 Context : so many programming languages Peter J. Landin: “The Next 700 Programming Languages”, CACM >>>>1966<<<<. Some programming-language ‘family trees’ (too big for slide): http://www.oreilly.com/go/languageposter http://www.levenez.com/lang/ http://rigaux.org/language-study/diagram.html http://www.rackspace.com/blog/ infographic-evolution-of-computer-languages/ Plan of this course: pick out interesting programming- language concepts and major evolutionary trends. 4 Topics I. Introduction and motivation. II. The first procedural language: FORTRAN (1954–58). III. The first declarative language: LISP (1958–62). IV. Block-structured procedural languages: Algol (1958–68), Pascal (1970). V. Object-oriented languages — Concepts and origins: Simula (1964–67), Smalltalk (1971–80). VI. Languages for concurrency and parallelism. VII. Types in programming languages: ML (1973–1978). VIII. Data abstraction and modularity: SML Modules (1984–97). IX. A modern language design: Scala (2007) X. Miscellaneous concepts 5 Topic I Introduction and motivation References: g g Chapter 1 of Concepts in programming languages by J.
    [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]