DOCSLIB.ORG

Is Structural Subtyping Useful? an Empirical Study

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Is Structural Subtyping Useful? An Empirical Study Donna Malayeri and Jonathan Aldrich Carnegie Mellon University, Pittsburgh, PA 15213, USA, fdonna, [email protected] Abstract. Structural subtyping is popular in research languages, but all main- stream object-oriented languages use nominal subtyping. Since languages with structural subtyping are not in widespread use, the empirical questions of whether and how structural subtyping is useful have thus far remained unanswered. This study aims to provide answers to these questions. We identified several criteria that are indicators that nominally typed programs could benefit from structural subtyping, and performed automated and manual analyses of open-source Java programs based on these criteria. Our results suggest that these programs could indeed be improved with the addition of structural subtyping. We hope this study will provide guidance for language designers who are considering use of this subtyping discipline. 1 Introduction Structural subtyping is popular in the research community and is used in languages such as O’Caml [15], PolyToil [6], Moby [11], Strongtalk [5], and a number of type systems and calculi (e.g., [7, 1]). In the research community, many believe that structural subtyp- ing is beneficial and is superior to nominal subtyping. But, structural subtyping is not used in any mainstream object-oriented programming language—perhaps due to lack of evidence of its utility. Accordingly, we ask: what empirical evidence could show that structural subtyping can be beneficial? Let us consider the characteristics that a nominally-typed program might exhibit that would indicate that it could benefit from structural subtyping. First, the program might systematically make use of a subset of methods of a type, with no nominal type corresponding to this method set. A particular such implicit type might be used repeat- edly throughout the program. Structural subtyping would allow these types to be easily expressed, without requiring that the type hierarchy of the program change. Second, there might be methods in two different classes that share the same name and perform the same operation, but that are not contained in a common nominal su- pertype. This could happen due to oversight, or perhaps the need did not yet exist to call that method in a generic manner for both classes. Alternatively, perhaps such a need did exist, but programmers resorted to code duplication rather than refactoring the type hierarchy. With structural subtyping, the two classes would automatically share a common supertype. Or, programs might use the Java reflection method Class.getMethod to call a method with a particular signature in a generic manner. Structural subtyping provides 1 exactly this capability, with no need for reflection. Finally, what might a class do if it can only support a subset of its declared interface, but no such super-interface can be defined (due to library use)? One implementation strategy is to have some of its methods always throw an UnsupportedOperationException. In contrast, with structural subtyping, the intended structural super-interface could simply be used. With these characteristics in mind, we examined up to 29 open-source Java pro- grams, using both manual and automated analyses (in the case of manual analyses, a subset of the subject programs were considered). Each aimed to answer one question: are nominally-typed programs using implicit structural types? We found that indeed they were; representing these types explicitly could therefore be advantageous. In our empirical evaluation, we sought to answer the following questions: 1. Does the body of a method use only a subset of the methods of its parameters? If so, structural types could ease the task of making the method more general. (Sect. 3) 2. If structural types are inferred for method parameters, do there exist types that are used repeatedly, suggesting that they represent a meaningful abstraction? (Sect. 3.3) 3. How many methods always throw “unsupported operation” exceptions? In such cases, classes support a structural supertype of the class type. (Sect. 4) 4. Do there exist common methods—methods with the same name and signature, but that are not contained in a common supertype of the enclosing classes? (Sect 5.1) 5. How many common methods represent an accidental name clash? (Sect 5.2) 6. Can structural subtyping reduce code duplication? (Sect. 5.3) 7. Is there synergy between structural subtyping and other proposed language fea- tures, such as multimethods? (Sect. 6) 8. Do programs use reflection where structural types would be preferable? (Sect. 7) Thus, we considered a variety of facets of existing programs. While none of these aspects is conclusive on its own, taken together, the answers to the above questions provide evidence that even programs written with a nominal subtyping discipline could benefit from structural subtyping. This study provides initial answers to the above ques- tions; further study is needed to fully examine all aspects of some questions, particularly questions 6 and 7. Additionally, this study considers only the potential benefits of struc- tural subtyping, while there are situations where nominal types are more appropriate [23, 17]. To our knowledge, this is the first systematic corpus analysis to determine the ben- efits of structural subtyping. This paper makes the following contributions: (1) iden- tification of a number of characteristics in a program that suggest the use of implicit structural types; and (2) results from automated and manual analyses that measure the identified characteristics. 2 Corpus and Methodology For this study, we analyzed the source code of up to 29 open-source Java applications (details, including version numbers, are provided in [18]). The full set of subject pro- grams were used for the automated analyses; due to practical considerations, for manual analysis we chose a subset thereof (ranging from 2 to 8 in size). The applications were chosen from the following sources: popular applications on SourceForge, Apache Foun- dation applications, and the DaCapo benchmark suite. The full set of programs range 2 from 12 kLOC to 161 kLOC, and for both kinds of analysis we selected programs based on size, type (library vs. standalone program) and domain (selecting for variety). For some of the manual analyses, we favored applications with which we were familiar, as this aided analysis. All of the manual analyses, including the subjective analyses, were performed by the first author. The methodology for each analysis is described in the corresponding section; further details are available in the companion technical report [18]. For space considerations, in this paper we have omitted data from the 10 smallest applications that were not already the subject of a manual analysis (in order that the manual analysis subject programs be a subset of the included automated analysis pro- grams). (There is one exception: Azureus was used in one manual analysis (Sect. 5.3), but was too large for our whole-program automated analyses.) We refer the reader to the companion technical report for full results [18]. 3 Inferring Structural Types for Method Parameters It is considered good programming practice to make parameters as general as the program allows. Bloch, for example, recommends favoring interfaces over classes in general—particularly so in the case of parameter types [3]. An analogous situation arises in the generic programming community, where it is recommended that generic algorithms and types place as few requirements as possible on their type parameters (e.g., what methods they should support) [22]. Bloch acknowledges that sometimes an appropriate interface does not exist (e.g., class java.util.Random does not implement any non-marker interfaces). In such a case the programmer is forced to use classes for parameter types—even though it is possible that multiple implementations of the same functionality could exist [3]. This is a situation where structural subtyping could be beneficial, as it allows programmers to create supertypes after-the-fact. As it is impossible to retroactively implement interfaces in Java, we hypothesized that method parameter types are often overly specific, and sought to determine both (1) the degree and (2) the character of over-specificity. To answer question (1), we per- formed an automated whole-program analysis to infer structural types for method pa- rameters. Methodology and quantitative results are described in Sect. 3.1. To properly interpret this data, however, we must consider question (2). Accordingly, we manually examined the inferred structural types from the previous analysis and considered the qualitative question of whether changing a method to have the most general structural type could potentially improve the method’s interface (Sect. 3.2). Across all applica- tions, we also counted occurrences of inferred structural types that were supertypes of classes and interfaces of the Java Collections Library. Of these, in Sect. 3.3 we present those structural types that a client might plausibly wish to implement while not simul- taneously implementing a more specific nominal type (e.g., Collection, Map, etc.). 3.1 Quantitative Results Our analysis infers structural types for method parameters, based on the methods that were actually called on the parameters. (For example, a method may take a List as an 3 argument, but may only use the add and iterator methods.) The analysis, a simple inter-procedural dataflow analysis, re-computes structural types for each parameter of a method until a fixpoint is reached. Details of the algorithm are described in the compan- ion technical report [18]. Structural types were not inferred in the following cases: calls to library methods, assignments to fields and local variables, uses of primitive types, uses of types such as String and Object, and cases where the inferred structural type would have a non-public member. The analysis is conservative; in the case where a parameter is not used (or only methods of class Object are used), no structural type is inferred for it.
Recommended publications
  • An Extended Theory of Primitive Objects: First Order System Luigi Liquori

    An Extended Theory of Primitive Objects: First Order System Luigi Liquori

    An extended Theory of Primitive Objects: First order system Luigi Liquori To cite this version: Luigi Liquori. An extended Theory of Primitive Objects: First order system. ECOOP, Jun 1997, Jyvaskyla, Finland. pp.146-169, 10.1007/BFb0053378. hal-01154568 HAL Id: hal-01154568 https://hal.inria.fr/hal-01154568 Submitted on 22 May 2015 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. An Extended Theory of Primitive Objects: First Order System Luigi Liquori ? Dip. Informatica, Universit`adi Torino, C.so Svizzera 185, I-10149 Torino, Italy e-mail: [email protected] Abstract. We investigate a first-order extension of the Theory of Prim- itive Objects of [5] that supports method extension in presence of object subsumption. Extension is the ability of modifying the behavior of an ob- ject by adding new methods (and inheriting the existing ones). Object subsumption allows to use objects with a bigger interface in a context expecting another object with a smaller interface. This extended calcu- lus has a sound type system which allows static detection of run-time errors such as message-not-understood, \width" subtyping and a typed equational theory on objects.
  • On Model Subtyping Cl´Ement Guy, Benoit Combemale, Steven Derrien, James Steel, Jean-Marc J´Ez´Equel

    On Model Subtyping Cl´Ement Guy, Benoit Combemale, Steven Derrien, James Steel, Jean-Marc J´Ez´Equel

    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by HAL-Rennes 1 On Model Subtyping Cl´ement Guy, Benoit Combemale, Steven Derrien, James Steel, Jean-Marc J´ez´equel To cite this version: Cl´ement Guy, Benoit Combemale, Steven Derrien, James Steel, Jean-Marc J´ez´equel.On Model Subtyping. ECMFA - 8th European Conference on Modelling Foundations and Applications, Jul 2012, Kgs. Lyngby, Denmark. 2012. <hal-00695034> HAL Id: hal-00695034 https://hal.inria.fr/hal-00695034 Submitted on 7 May 2012 HAL is a multi-disciplinary open access L'archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destin´eeau d´ep^otet `ala diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publi´esou non, lished or not. The documents may come from ´emanant des ´etablissements d'enseignement et de teaching and research institutions in France or recherche fran¸caisou ´etrangers,des laboratoires abroad, or from public or private research centers. publics ou priv´es. On Model Subtyping Clément Guy1, Benoit Combemale1, Steven Derrien1, Jim R. H. Steel2, and Jean-Marc Jézéquel1 1 University of Rennes1, IRISA/INRIA, France 2 University of Queensland, Australia Abstract. Various approaches have recently been proposed to ease the manipu- lation of models for specific purposes (e.g., automatic model adaptation or reuse of model transformations). Such approaches raise the need for a unified theory that would ease their combination, but would also outline the scope of what can be expected in terms of engineering to put model manipulation into action.
  • CS 61A Streams Summer 2019 1 Streams

    CS 61A Streams Summer 2019 1 Streams

    CS 61A Streams Summer 2019 Discussion 10: August 6, 2019 1 Streams In Python, we can use iterators to represent infinite sequences (for example, the generator for all natural numbers). However, Scheme does not support iterators. Let's see what happens when we try to use a Scheme list to represent an infinite sequence of natural numbers: scm> (define (naturals n) (cons n (naturals (+ n 1)))) naturals scm> (naturals 0) Error: maximum recursion depth exceeded Because cons is a regular procedure and both its operands must be evaluted before the pair is constructed, we cannot create an infinite sequence of integers using a Scheme list. Instead, our Scheme interpreter supports streams, which are lazy Scheme lists. The first element is represented explicitly, but the rest of the stream's elements are computed only when needed. Computing a value only when it's needed is also known as lazy evaluation. scm> (define (naturals n) (cons-stream n (naturals (+ n 1)))) naturals scm> (define nat (naturals 0)) nat scm> (car nat) 0 scm> (cdr nat) #[promise (not forced)] scm> (car (cdr-stream nat)) 1 scm> (car (cdr-stream (cdr-stream nat))) 2 We use the special form cons-stream to create a stream: (cons-stream <operand1> <operand2>) cons-stream is a special form because the second operand is not evaluated when evaluating the expression. To evaluate this expression, Scheme does the following: 1. Evaluate the first operand. 2. Construct a promise containing the second operand. 3. Return a pair containing the value of the first operand and the promise. 2 Streams To actually get the rest of the stream, we must call cdr-stream on it to force the promise to be evaluated.
  • Chapter 2 Basics of Scanning And

    Chapter 2 Basics of Scanning And

    Chapter 2 Basics of Scanning and Conventional Programming in Java In this chapter, we will introduce you to an initial set of Java features, the equivalent of which you should have seen in your CS-1 class; the separation of problem, representation, algorithm and program – four concepts you have probably seen in your CS-1 class; style rules with which you are probably familiar, and scanning - a general class of problems we see in both computer science and other fields. Each chapter is associated with an animating recorded PowerPoint presentation and a YouTube video created from the presentation. It is meant to be a transcript of the associated presentation that contains little graphics and thus can be read even on a small device. You should refer to the associated material if you feel the need for a different instruction medium. Also associated with each chapter is hyperlinked code examples presented here. References to previously presented code modules are links that can be traversed to remind you of the details. The resources for this chapter are: PowerPoint Presentation YouTube Video Code Examples Algorithms and Representation Four concepts we explicitly or implicitly encounter while programming are problems, representations, algorithms and programs. Programs, of course, are instructions executed by the computer. Problems are what we try to solve when we write programs. Usually we do not go directly from problems to programs. Two intermediate steps are creating algorithms and identifying representations. Algorithms are sequences of steps to solve problems. So are programs. Thus, all programs are algorithms but the reverse is not true.
  • File I/O Stream Byte Stream

    File I/O Stream Byte Stream

    File I/O In Java, we can read data from files and also write data in files. We do this using streams. Java has many input and output streams that are used to read and write data. Same as a continuous flow of water is called water stream, in the same way input and output flow of data is called stream. Stream Java provides many input and output stream classes which are used to read and write. Streams are of two types. Byte Stream Character Stream Let's look at the two streams one by one. Byte Stream It is used in the input and output of byte. We do this with the help of different Byte stream classes. Two most commonly used Byte stream classes are FileInputStream and FileOutputStream. Some of the Byte stream classes are listed below. Byte Stream Description BufferedInputStream handles buffered input stream BufferedOutputStrea handles buffered output stream m FileInputStream used to read from a file FileOutputStream used to write to a file InputStream Abstract class that describe input stream OutputStream Abstract class that describe output stream Byte Stream Classes are in divided in two groups - InputStream Classes - These classes are subclasses of an abstract class, InputStream and they are used to read bytes from a source(file, memory or console). OutputStream Classes - These classes are subclasses of an abstract class, OutputStream and they are used to write bytes to a destination(file, memory or console). InputStream InputStream class is a base class of all the classes that are used to read bytes from a file, memory or console.
  • C++ Input/Output: Streams 4

    C++ Input/Output: Streams 4

    C++ Input/Output: Streams 4. Input/Output 1 The basic data type for I/O in C++ is the stream. C++ incorporates a complex hierarchy of stream types. The most basic stream types are the standard input/output streams: istream cin built-in input stream variable; by default hooked to keyboard ostream cout built-in output stream variable; by default hooked to console header file: <iostream> C++ also supports all the input/output mechanisms that the C language included. However, C++ streams provide all the input/output capabilities of C, with substantial improvements. We will exclusively use streams for input and output of data. Computer Science Dept Va Tech August, 2001 Intro Programming in C++ ©1995-2001 Barnette ND & McQuain WD C++ Streams are Objects 4. Input/Output 2 The input and output streams, cin and cout are actually C++ objects. Briefly: class: a C++ construct that allows a collection of variables, constants, and functions to be grouped together logically under a single name object: a variable of a type that is a class (also often called an instance of the class) For example, istream is actually a type name for a class. cin is the name of a variable of type istream. So, we would say that cin is an instance or an object of the class istream. An instance of a class will usually have a number of associated functions (called member functions) that you can use to perform operations on that object or to obtain information about it. The following slides will present a few of the basic stream member functions, and show how to go about using member functions.
  • Subtyping Recursive Types

    Subtyping Recursive Types

    ACM Transactions on Programming Languages and Systems, 15(4), pp. 575-631, 1993. Subtyping Recursive Types Roberto M. Amadio1 Luca Cardelli CNRS-CRIN, Nancy DEC, Systems Research Center Abstract We investigate the interactions of subtyping and recursive types, in a simply typed λ-calculus. The two fundamental questions here are whether two (recursive) types are in the subtype relation, and whether a term has a type. To address the first question, we relate various definitions of type equivalence and subtyping that are induced by a model, an ordering on infinite trees, an algorithm, and a set of type rules. We show soundness and completeness between the rules, the algorithm, and the tree semantics. We also prove soundness and a restricted form of completeness for the model. To address the second question, we show that to every pair of types in the subtype relation we can associate a term whose denotation is the uniquely determined coercion map between the two types. Moreover, we derive an algorithm that, when given a term with implicit coercions, can infer its least type whenever possible. 1This author's work has been supported in part by Digital Equipment Corporation and in part by the Stanford-CNR Collaboration Project. Page 1 Contents 1. Introduction 1.1 Types 1.2 Subtypes 1.3 Equality of Recursive Types 1.4 Subtyping of Recursive Types 1.5 Algorithm outline 1.6 Formal development 2. A Simply Typed λ-calculus with Recursive Types 2.1 Types 2.2 Terms 2.3 Equations 3. Tree Ordering 3.1 Subtyping Non-recursive Types 3.2 Folding and Unfolding 3.3 Tree Expansion 3.4 Finite Approximations 4.
  • Subtyping, Declaratively an Exercise in Mixed Induction and Coinduction

    Subtyping, Declaratively an Exercise in Mixed Induction and Coinduction

    Subtyping, Declaratively An Exercise in Mixed Induction and Coinduction Nils Anders Danielsson and Thorsten Altenkirch University of Nottingham Abstract. It is natural to present subtyping for recursive types coin- ductively. However, Gapeyev, Levin and Pierce have noted that there is a problem with coinductive definitions of non-trivial transitive inference systems: they cannot be \declarative"|as opposed to \algorithmic" or syntax-directed|because coinductive inference systems with an explicit rule of transitivity are trivial. We propose a solution to this problem. By using mixed induction and coinduction we define an inference system for subtyping which combines the advantages of coinduction with the convenience of an explicit rule of transitivity. The definition uses coinduction for the structural rules, and induction for the rule of transitivity. We also discuss under what condi- tions this technique can be used when defining other inference systems. The developments presented in the paper have been mechanised using Agda, a dependently typed programming language and proof assistant. 1 Introduction Coinduction and corecursion are useful techniques for defining and reasoning about things which are potentially infinite, including streams and other (poten- tially) infinite data types (Coquand 1994; Gim´enez1996; Turner 2004), process congruences (Milner 1990), congruences for functional programs (Gordon 1999), closures (Milner and Tofte 1991), semantics for divergence of programs (Cousot and Cousot 1992; Hughes and Moran 1995; Leroy and Grall 2009; Nakata and Uustalu 2009), and subtyping relations for recursive types (Brandt and Henglein 1998; Gapeyev et al. 2002). However, the use of coinduction can lead to values which are \too infinite”. For instance, a non-trivial binary relation defined as a coinductive inference sys- tem cannot include the rule of transitivity, because a coinductive reading of transitivity would imply that every element is related to every other (to see this, build an infinite derivation consisting solely of uses of transitivity).
  • Generic Programming

    Generic Programming

    Generic Programming July 21, 1998 A Dagstuhl Seminar on the topic of Generic Programming was held April 27– May 1, 1998, with forty seven participants from ten countries. During the meeting there were thirty seven lectures, a panel session, and several problem sessions. The outcomes of the meeting include • A collection of abstracts of the lectures, made publicly available via this booklet and a web site at http://www-ca.informatik.uni-tuebingen.de/dagstuhl/gpdag.html. • Plans for a proceedings volume of papers submitted after the seminar that present (possibly extended) discussions of the topics covered in the lectures, problem sessions, and the panel session. • A list of generic programming projects and open problems, which will be maintained publicly on the World Wide Web at http://www-ca.informatik.uni-tuebingen.de/people/musser/gp/pop/index.html http://www.cs.rpi.edu/˜musser/gp/pop/index.html. 1 Contents 1 Motivation 3 2 Standards Panel 4 3 Lectures 4 3.1 Foundations and Methodology Comparisons ........ 4 Fundamentals of Generic Programming.................. 4 Jim Dehnert and Alex Stepanov Automatic Program Specialization by Partial Evaluation........ 4 Robert Gl¨uck Evaluating Generic Programming in Practice............... 6 Mehdi Jazayeri Polytypic Programming........................... 6 Johan Jeuring Recasting Algorithms As Objects: AnAlternativetoIterators . 7 Murali Sitaraman Using Genericity to Improve OO Designs................. 8 Karsten Weihe Inheritance, Genericity, and Class Hierarchies.............. 8 Wolf Zimmermann 3.2 Programming Methodology ................... 9 Hierarchical Iterators and Algorithms................... 9 Matt Austern Generic Programming in C++: Matrix Case Study........... 9 Krzysztof Czarnecki Generative Programming: Beyond Generic Programming........ 10 Ulrich Eisenecker Generic Programming Using Adaptive and Aspect-Oriented Programming .
  • Java for Scientific Computing, Pros and Cons

    Java for Scientific Computing, Pros and Cons

    Journal of Universal Computer Science, vol. 4, no. 1 (1998), 11-15 submitted: 25/9/97, accepted: 1/11/97, appeared: 28/1/98 Springer Pub. Co. Java for Scienti c Computing, Pros and Cons Jurgen Wol v. Gudenb erg Institut fur Informatik, Universitat Wurzburg wol @informatik.uni-wuerzburg.de Abstract: In this article we brie y discuss the advantages and disadvantages of the language Java for scienti c computing. We concentrate on Java's typ e system, investi- gate its supp ort for hierarchical and generic programming and then discuss the features of its oating-p oint arithmetic. Having found the weak p oints of the language we pro- p ose workarounds using Java itself as long as p ossible. 1 Typ e System Java distinguishes b etween primitive and reference typ es. Whereas this distinc- tion seems to b e very natural and helpful { so the primitives which comprise all standard numerical data typ es have the usual value semantics and expression concept, and the reference semantics of the others allows to avoid p ointers at all{ it also causes some problems. For the reference typ es, i.e. arrays, classes and interfaces no op erators are available or may b e de ned and expressions can only b e built by metho d calls. Several variables may simultaneously denote the same ob ject. This is certainly strange in a numerical setting, but not to avoid, since classes have to b e used to intro duce higher data typ es. On the other hand, the simple hierarchy of classes with the ro ot Object clearly b elongs to the advantages of the language.
  • 13 Templates-Generics.Pdf

    13 Templates-Generics.Pdf

    CS 242 2012 Generic programming in OO Languages Reading Text: Sections 9.4.1 and 9.4.3 J Koskinen, Metaprogramming in C++, Sections 2 – 5 Gilad Bracha, Generics in the Java Programming Language Questions • If subtyping and inheritance are so great, why do we need type parameterization in object- oriented languages? • The great polymorphism debate – Subtype polymorphism • Apply f(Object x) to any y : C <: Object – Parametric polymorphism • Apply generic <T> f(T x) to any y : C Do these serve similar or different purposes? Outline • C++ Templates – Polymorphism vs Overloading – C++ Template specialization – Example: Standard Template Library (STL) – C++ Template metaprogramming • Java Generics – Subtyping versus generics – Static type checking for generics – Implementation of Java generics Polymorphism vs Overloading • Parametric polymorphism – Single algorithm may be given many types – Type variable may be replaced by any type – f :: tt => f :: IntInt, f :: BoolBool, ... • Overloading – A single symbol may refer to more than one algorithm – Each algorithm may have different type – Choice of algorithm determined by type context – Types of symbol may be arbitrarily different – + has types int*intint, real*realreal, ... Polymorphism: Haskell vs C++ • Haskell polymorphic function – Declarations (generally) require no type information – Type inference uses type variables – Type inference substitutes for variables as needed to instantiate polymorphic code • C++ function template – Programmer declares argument, result types of fctns – Programmers
  • Data-Trace Types for Distributed Stream Processing Systems

    Data-Trace Types for Distributed Stream Processing Systems

    Data-Trace Types for Distributed Stream Processing Systems Konstantinos Mamouras Caleb Stanford Rajeev Alur Rice University, USA University of Pennsylvania, USA University of Pennsylvania, USA [email protected] [email protected] [email protected] Zachary G. Ives Val Tannen University of Pennsylvania, USA University of Pennsylvania, USA [email protected] [email protected] Abstract guaranteeing correct deployment, and (2) the throughput of Distributed architectures for efficient processing of stream- the automatically compiled distributed code is comparable ing data are increasingly critical to modern information pro- to that of hand-crafted distributed implementations. cessing systems. The goal of this paper is to develop type- CCS Concepts • Information systems → Data streams; based programming abstractions that facilitate correct and Stream management; • Theory of computation → Stream- efficient deployment of a logical specification of the desired ing models; • Software and its engineering → General computation on such architectures. In the proposed model, programming languages. each communication link has an associated type specifying tagged data items along with a dependency relation over tags Keywords distributed data stream processing, types that captures the logical partial ordering constraints over data items. The semantics of a (distributed) stream process- ACM Reference Format: ing system is then a function from input data traces to output Konstantinos Mamouras, Caleb Stanford, Rajeev Alur, Zachary data traces, where a data trace is an equivalence class of se- G. Ives, and Val Tannen. 2019. Data-Trace Types for Distributed quences of data items induced by the dependency relation. Stream Processing Systems. In Proceedings of the 40th ACM SIGPLAN Conference on Programming Language Design and Implementation This data-trace transduction model generalizes both acyclic (PLDI ’19), June 22–26, 2019, Phoenix, AZ, USA.