Asynchronous Liquid Separation Types
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
X10 Language Specification
X10 Language Specification Version 2.6.2 Vijay Saraswat, Bard Bloom, Igor Peshansky, Olivier Tardieu, and David Grove Please send comments to [email protected] January 4, 2019 This report provides a description of the programming language X10. X10 is a class- based object-oriented programming language designed for high-performance, high- productivity computing on high-end computers supporting ≈ 105 hardware threads and ≈ 1015 operations per second. X10 is based on state-of-the-art object-oriented programming languages and deviates from them only as necessary to support its design goals. The language is intended to have a simple and clear semantics and be readily accessible to mainstream OO pro- grammers. It is intended to support a wide variety of concurrent programming idioms. The X10 design team consists of David Grove, Ben Herta, Louis Mandel, Josh Milthorpe, Vijay Saraswat, Avraham Shinnar, Mikio Takeuchi, Olivier Tardieu. Past members include Shivali Agarwal, Bowen Alpern, David Bacon, Raj Barik, Ganesh Bikshandi, Bob Blainey, Bard Bloom, Philippe Charles, Perry Cheng, David Cun- ningham, Christopher Donawa, Julian Dolby, Kemal Ebcioglu,˘ Stephen Fink, Robert Fuhrer, Patrick Gallop, Christian Grothoff, Hiroshi Horii, Kiyokuni Kawachiya, Al- lan Kielstra, Sreedhar Kodali, Sriram Krishnamoorthy, Yan Li, Bruce Lucas, Yuki Makino, Nathaniel Nystrom, Igor Peshansky, Vivek Sarkar, Armando Solar-Lezama, S. Alexander Spoon, Toshio Suganuma, Sayantan Sur, Toyotaro Suzumura, Christoph von Praun, Leena Unnikrishnan, Pradeep Varma, Krishna Nandivada Venkata, Jan Vitek, Hai Chuan Wang, Tong Wen, Salikh Zakirov, and Yoav Zibin. For extended discussions and support we would like to thank: Gheorghe Almasi, Robert Blackmore, Rob O’Callahan, Calin Cascaval, Norman Cohen, Elmootaz El- nozahy, John Field, Kevin Gildea, Sara Salem Hamouda, Michihiro Horie, Arun Iyen- gar, Chulho Kim, Orren Krieger, Doug Lea, John McCalpin, Paul McKenney, Hiroki Murata, Andrew Myers, Filip Pizlo, Ram Rajamony, R. -
Irrelevance, Heterogeneous Equality, and Call-By-Value Dependent Type Systems
Irrelevance, Heterogeneous Equality, and Call-by-value Dependent Type Systems Vilhelm Sjoberg¨ Chris Casinghino Ki Yung Ahn University of Pennsylvania University of Pennsylvania Portland State University [email protected] [email protected] [email protected] Nathan Collins Harley D. Eades III Peng Fu Portland State University University of Iowa University of Iowa [email protected] [email protected] [email protected] Garrin Kimmell Tim Sheard Aaron Stump University of Iowa Portland State University University of Iowa [email protected] [email protected] [email protected] Stephanie Weirich University of Pennsylvania [email protected] We present a full-spectrum dependently typed core language which includes both nontermination and computational irrelevance (a.k.a. erasure), a combination which has not been studied before. The two features interact: to protect type safety we must be careful to only erase terminating expressions. Our language design is strongly influenced by the choice of CBV evaluation, and by our novel treatment of propositional equality which has a heterogeneous, completely erased elimination form. 1 Introduction The Trellys project is a collaborative effort to design a new dependently typed programming language. Our goal is to bridge the gap between ordinary functional programming and program verification with dependent types. Programmers should be able to port their existing functional programs to Trellys with minor modifications, and then gradually add more expressive types as appropriate. This goal has implications for our design. First, and most importantly, we must consider nonter- mination and other effects. Unlike Coq and Agda, functional programming languages like OCaml and Haskell allow general recursive functions, so to accept functional programs ‘as-is’ we must be able to turn off the termination checker. -
Exploring Languages with Interpreters and Functional Programming Chapter 22
Exploring Languages with Interpreters and Functional Programming Chapter 22 H. Conrad Cunningham 5 November 2018 Contents 22 Overloading and Type Classes 2 22.1 Chapter Introduction . .2 22.2 Polymorphism in Haskell . .2 22.3 Why Overloading? . .2 22.4 Defining an Equality Class and Its Instances . .4 22.5 Type Class Laws . .5 22.6 Another Example Class Visible ..................5 22.7 Class Extension (Inheritance) . .6 22.8 Multiple Constraints . .7 22.9 Built-In Haskell Classes . .8 22.10Comparison to Other Languages . .8 22.11What Next? . .9 22.12Exercises . 10 22.13Acknowledgements . 10 22.14References . 11 22.15Terms and Concepts . 11 Copyright (C) 2017, 2018, H. Conrad Cunningham Professor of Computer and Information Science University of Mississippi 211 Weir Hall P.O. Box 1848 University, MS 38677 (662) 915-5358 Browser Advisory: The HTML version of this textbook requires use of a browser that supports the display of MathML. A good choice as of November 2018 is a recent version of Firefox from Mozilla. 1 22 Overloading and Type Classes 22.1 Chapter Introduction Chapter 5 introduced the concept of overloading. Chapters 13 and 21 introduced the related concepts of type classes and instances. The goal of this chapter and the next chapter is to explore these concepts in more detail. The concept of type class was introduced into Haskell to handle the problem of comparisons, but it has had a broader and more profound impact upon the development of the language than its original purpose. This Haskell feature has also had a significant impact upon the design of subsequent languages (e.g. -
Why Dependent Types Matter
Why Dependent Types Matter Thorsten Altenkirch Conor McBride James McKinna The University of Nottingham The University of St Andrews {txa,ctm}@cs.nott.ac.uk [email protected] Abstract We exhibit the rationale behind the design of Epigram, a dependently typed programming language and interactive program development system, using refinements of a well known program—merge sort—as a running example. We discuss its relationship with other proposals to introduce aspects of dependent types into functional programming languages and sketch some topics for further work in this area. 1. Introduction Types matter. That’s what they’re for—to classify data with respect to criteria which matter: how they should be stored in memory, whether they can be safely passed as inputs to a given operation, even who is allowed to see them. Dependent types are types expressed in terms of data, explicitly relating their inhabitants to that data. As such, they enable you to express more of what matters about data. While conventional type systems allow us to validate our programs with respect to a fixed set of criteria, dependent types are much more flexible, they realize a continuum of precision from the basic assertions we are used to expect from types up to a complete specification of the program’s behaviour. It is the programmer’s choice to what degree he wants to exploit the expressiveness of such a powerful type discipline. While the price for formally certified software may be high, it is good to know that we can pay it in installments and that we are free to decide how far we want to go. -
On the Interaction of Object-Oriented Design Patterns and Programming
On the Interaction of Object-Oriented Design Patterns and Programming Languages Gerald Baumgartner∗ Konstantin L¨aufer∗∗ Vincent F. Russo∗∗∗ ∗ Department of Computer and Information Science The Ohio State University 395 Dreese Lab., 2015 Neil Ave. Columbus, OH 43210–1277, USA [email protected] ∗∗ Department of Mathematical and Computer Sciences Loyola University Chicago 6525 N. Sheridan Rd. Chicago, IL 60626, USA [email protected] ∗∗∗ Lycos, Inc. 400–2 Totten Pond Rd. Waltham, MA 02154, USA [email protected] February 29, 1996 Abstract Design patterns are distilled from many real systems to catalog common programming practice. However, some object-oriented design patterns are distorted or overly complicated because of the lack of supporting programming language constructs or mechanisms. For this paper, we have analyzed several published design patterns looking for idiomatic ways of working around constraints of the implemen- tation language. From this analysis, we lay a groundwork of general-purpose language constructs and mechanisms that, if provided by a statically typed, object-oriented language, would better support the arXiv:1905.13674v1 [cs.PL] 31 May 2019 implementation of design patterns and, transitively, benefit the construction of many real systems. In particular, our catalog of language constructs includes subtyping separate from inheritance, lexically scoped closure objects independent of classes, and multimethod dispatch. The proposed constructs and mechanisms are not radically new, but rather are adopted from a variety of languages and programming language research and combined in a new, orthogonal manner. We argue that by describing design pat- terns in terms of the proposed constructs and mechanisms, pattern descriptions become simpler and, therefore, accessible to a larger number of language communities. -
An Analysis of the Dynamic Behavior of Javascript Programs
An Analysis of the Dynamic Behavior of JavaScript Programs Gregor Richards Sylvain Lebresne Brian Burg Jan Vitek S3 Lab, Department of Computer Science, Purdue University, West Lafayette, IN fgkrichar,slebresn,bburg,[email protected] Abstract becoming a general purpose computing platform with office appli- The JavaScript programming language is widely used for web cations, browsers and development environments [15] being devel- programming and, increasingly, for general purpose computing. oped in JavaScript. It has been dubbed the “assembly language” of the Internet and is targeted by code generators from the likes As such, improving the correctness, security and performance of 2;3 JavaScript applications has been the driving force for research in of Java and Scheme [20]. In response to this success, JavaScript type systems, static analysis and compiler techniques for this lan- has started to garner academic attention and respect. Researchers guage. Many of these techniques aim to reign in some of the most have focused on three main problems: security, correctness and dynamic features of the language, yet little seems to be known performance. Security is arguably JavaScript’s most pressing prob- about how programmers actually utilize the language or these fea- lem: a number of attacks have been discovered that exploit the lan- tures. In this paper we perform an empirical study of the dynamic guage’s dynamism (mostly the ability to access and modify shared behavior of a corpus of widely-used JavaScript programs, and an- objects and to inject code via eval). Researchers have proposed ap- alyze how and why the dynamic features are used. -
Thinking in C++ Volume 2 Annotated Solution Guide, Available for a Small Fee From
1 z 516 Note: This document requires the installation of the fonts Georgia, Verdana and Andale Mono (code font) for proper viewing. These can be found at: http://sourceforge.net/project/showfiles.php?group_id=34153&release_id=105355 Revision 19—(August 23, 2003) Finished Chapter 11, which is now going through review and copyediting. Modified a number of examples throughout the book so that they will compile with Linux g++ (basically fixing case- sensitive naming issues). Revision 18—(August 2, 2003) Chapter 5 is complete. Chapter 11 is updated and is near completion. Updated the front matter and index entries. Home stretch now. Revision 17—(July 8, 2003) Chapters 5 and 11 are 90% done! Revision 16—(June 25, 2003) Chapter 5 text is almost complete, but enough is added to justify a separate posting. The example programs for Chapter 11 are also fairly complete. Added a matrix multiplication example to the valarray material in chapter 7. Chapter 7 has been tech-edited. Many corrections due to comments from users have been integrated into the text (thanks!). Revision 15—(March 1 ,2003) Fixed an omission in C10:CuriousSingleton.cpp. Chapters 9 and 10 have been tech-edited. Revision 14—(January ,2003) Fixed a number of fuzzy explanations in response to reader feedback (thanks!). Chapter 9 has been copy-edited. Revision 13—(December 31, 2002) Updated the exercises for Chapter 7. Finished rewriting Chapter 9. Added a template variation of Singleton to chapter 10. Updated the build directives. Fixed lots of stuff. Chapters 5 and 11 still await rewrite. Revision 12—(December 23, 2002) Added material on Design Patterns as Chapter 10 (Concurrency will move to Chapter 11). -
Dependent Types: Easy As PIE
Dependent Types: Easy as PIE Work-In-Progress Project Description Dimitrios Vytiniotis and Stephanie Weirich University of Pennsylvania Abstract Dependent type systems allow for a rich set of program properties to be expressed and mechanically verified via type checking. However, despite their significant expres- sive power, dependent types have not yet advanced into mainstream programming languages. We believe the reason behind this omission is the large design space for dependently typed functional programming languages, and the consequent lack of ex- perience in dependently-typed programming and language implementations. In this newly-started project, we lay out the design considerations for a general-purpose, ef- fectful, functional, dependently-typed language, called PIE. The goal of this project is to promote dependently-typed programming to a mainstream practice. 1 INTRODUCTION The goal of static type systems is to identify programs that contain errors. The type systems of functional languages, such as ML and Haskell, have been very successful in this respect. However, these systems can ensure only relatively weak safety properties—there is a wide range of semantic errors that these systems can- not eliminate. As a result, there is growing consensus [13, 15, 28, 27, 26, 6, 7, 20, 21, 16, 11, 2, 25, 19, 1, 22] that the right way to make static type systems more expressive in this respect is to adopt ideas from dependent type theory [12]. Types in dependent type systems can carry significant information about program values. For example, a datatype for network packets may describe the internal byte align- ment of variable-length subfields. In such precise type systems, programmers can express many of complex properties about programs—e.g. -
Dependent Types and Program Equivalence
University of Pennsylvania ScholarlyCommons Departmental Papers (CIS) Department of Computer & Information Science 1-17-2010 Dependent types and Program Equivalence Limin Jia University of Pennsylvania Jianzhou Zhao University of Pennsylvania Vilhelm Sjoberg University of Pennsylvania Stephanie Weirich University of Pennsylvania, [email protected] Follow this and additional works at: https://repository.upenn.edu/cis_papers Part of the Computer Sciences Commons Recommended Citation Limin Jia, Jianzhou Zhao, Vilhelm Sjoberg, and Stephanie Weirich, "Dependent types and Program Equivalence", . January 2010. © ACM, 2010. This is the author's version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in 37th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages, {(2010)} http://doi.acm.org/10.1145/10.1145/1707801.1706333 Email [email protected] This paper is posted at ScholarlyCommons. https://repository.upenn.edu/cis_papers/632 For more information, please contact [email protected]. Dependent types and Program Equivalence Abstract The definition of type equivalence is one of the most important design issues for any typed language. In dependently-typed languages, because terms appear in types, this definition must elyr on a definition of term equivalence. In that case, decidability of type checking requires decidability for the term equivalence relation. Almost all dependently-typed languages require this relation to be decidable. Some, such as Coq, Epigram or Agda, do so by employing analyses to force all programs to terminate. Conversely, others, such as DML, ATS, Omega, or Haskell, allow nonterminating computation, but do not allow those terms to appear in types. -
Ferrite: a Judgmental Embedding of Session Types in Rust
Ferrite: A Judgmental Embedding of Session Types in Rust RUOFEI CHEN, Independent Researcher, Germany STEPHANIE BALZER, Carnegie Mellon University, USA This paper introduces Ferrite, a shallow embedding of session types in Rust. In contrast to existing session type libraries and embeddings for mainstream languages, Ferrite not only supports linear session types but also shared session types. Shared session types allow sharing (aliasing) of channels while preserving session fidelity (preservation) using type modalities for acquiring and releasing sessions. Ferrite adopts a propositions as types approach and encodes typing derivations as Rust functions, with the proof of successful type-checking manifesting as a Rust program. We provide an evaluation of Ferrite using Servo as a practical example, and demonstrate how safe communication can be achieved in the canvas component using Ferrite. CCS Concepts: • Theory of computation ! Linear logic; Type theory; • Software and its engineering ! Domain specific languages; Concurrent programming languages. Additional Key Words and Phrases: Session Types, Rust, DSL ACM Reference Format: Ruofei Chen and Stephanie Balzer. 2021. Ferrite: A Judgmental Embedding of Session Types in Rust. In Proceedings of International Conference on Functional Programming (ICFP 2021). ACM, New York, NY, USA, 36 pages. 1 INTRODUCTION Message-passing concurrency is a dominant concurrency paradigm, adopted by mainstream lan- guages such as Erlang, Scala, Go, and Rust, putting the slogan “to share memory by communicating rather than communicating by sharing memory”[Gerrand 2010; Klabnik and Nichols 2018] into practice. In this setting, messages are exchanged over channels, which can be shared among several senders and recipients. Figure 1 provides a simplified example in Rust. -
A Formulation of Dependent ML with Explicit Equality Proofs
A Formulation of Dependent ML with Explicit Equality Proofs Daniel R. Licata Robert Harper December, 2005 CMU-CS-05-178 School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Abstract We study a calculus that supports dependent programming in the style of Xi and Pfenning’s Dependent ML. Xi and Pfenning’s language determines equality of static data using a built-in decision procedure; ours permits explicit, programmer-written proofs of equality. In this report, we define our calculus’ semantics and prove type safety and decidability of type checking; we have mechanized much of these proofs using the Twelf proof assistant. Additionally, we illustrate programming in our calculus through a series of examples. Finally, we present a detailed comparison with other dependently typed languages, including Dependent ML, Epigram, Cayenne, ATS, Ωmega, and RSP1. This material is based on work supported in part by the National Science Foundation under grants CCR-0204248: Type Refinements and 0121633: ITR/SY+SI: Language Technology for Trustless Software Dissemination. Any opinions, findings, conclusions and recommendations in this publication are the authors’ and do not reflect the views of this agency. Keywords: type systems, dependent types, ML, phase distinction, explicit proofs 1 Introduction 1.1 Dependent Types Consider the following signature for a module implementing lists of strings: signature STRING LIST = sig type slist val nil : slist val cons : string × slist → slist val append : slist × slist → slist val nth : slist × nat -
A Formulation of Dependent ML with Explicit Equality Proofs
A Formulation of Dependent ML with Explicit Equality Proofs Daniel R. Licata Robert Harper December, 2005 CMU-CS-05-178 School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Abstract We study a calculus that supports dependent programming in the style of Xi and Pfenning’s Dependent ML. Xi and Pfenning’s language determines equality of static data using a built-in decision procedure; ours permits explicit, programmer-written proofs of equality. In this report, we define our calculus’ semantics and prove type safety and decidability of type checking; we have mechanized much of these proofs using the Twelf proof assistant. Additionally, we illustrate programming in our calculus through a series of examples. Finally, we present a detailed comparison with other dependently typed languages, including Dependent ML, Epigram, Cayenne, ATS, Ωmega, and RSP1. This material is based on work supported in part by the National Science Foundation under grants CCR-0204248: Type Refinements and 0121633: ITR/SY+SI: Language Technology for Trustless Software Dissemination. Any opinions, findings, conclusions and recommendations in this publication are the authors’ and do not reflect the views of this agency. Keywords: dependent types, ML, explicit proofs, phase distinction 1 Introduction 1.1 Dependent Types Consider the following signature for a module implementing lists of strings: signature STRING LIST = sig type slist val nil : slist val cons : string × slist → slist val append : slist × slist → slist val nth : slist × nat → string val