Disjoint intersection types

B. C. D. S. Oliveira, Zhiyuan Shi, J. Alpuim
{"title":"Disjoint intersection types","authors":"B. C. D. S. Oliveira, Zhiyuan Shi, J. Alpuim","doi":"10.1145/2951913.2951945","DOIUrl":null,"url":null,"abstract":"Dunfield showed that a simply typed core calculus with intersection types and a merge operator is able to capture various programming language features. While his calculus is type-safe, it is not coherent: different derivations for the same expression can elaborate to expressions that evaluate to different values. The lack of coherence is an important disadvantage for adoption of his core calculus in implementations of programming languages, as the semantics of the programming language becomes implementation-dependent. This paper presents λ_i: a coherent and type-safe calculus with a form of intersection types and a merge operator. Coherence is achieved by ensuring that intersection types are disjoint and programs are sufficiently annotated to avoid type ambiguity. We propose a definition of disjointness where two types A and B are disjoint only if certain set of types are common supertypes of A and B. We investigate three different variants of λ_i, with three variants of disjointness. In the simplest variant, which does not allow ⊤ types, two types are disjoint if they do not share any common supertypes at all. The other two variants introduce ⊤ types and refine the notion of disjointness to allow two types to be disjoint when the only the set of common supertypes are top-like. The difference between the two variants with ⊤ types is on the definition of top-like types, which has an impact on which types are allowed on intersections. We present a type system that prevents intersection types that are not disjoint, as well as an algorithmic specifications to determine whether two types are disjoint for all three variants.","PeriodicalId":336660,"journal":{"name":"Proceedings of the 21st ACM SIGPLAN International Conference on Functional Programming","volume":"30 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2016-09-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"31","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"Proceedings of the 21st ACM SIGPLAN International Conference on Functional Programming","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/2951913.2951945","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 31

Abstract

Dunfield showed that a simply typed core calculus with intersection types and a merge operator is able to capture various programming language features. While his calculus is type-safe, it is not coherent: different derivations for the same expression can elaborate to expressions that evaluate to different values. The lack of coherence is an important disadvantage for adoption of his core calculus in implementations of programming languages, as the semantics of the programming language becomes implementation-dependent. This paper presents λ_i: a coherent and type-safe calculus with a form of intersection types and a merge operator. Coherence is achieved by ensuring that intersection types are disjoint and programs are sufficiently annotated to avoid type ambiguity. We propose a definition of disjointness where two types A and B are disjoint only if certain set of types are common supertypes of A and B. We investigate three different variants of λ_i, with three variants of disjointness. In the simplest variant, which does not allow ⊤ types, two types are disjoint if they do not share any common supertypes at all. The other two variants introduce ⊤ types and refine the notion of disjointness to allow two types to be disjoint when the only the set of common supertypes are top-like. The difference between the two variants with ⊤ types is on the definition of top-like types, which has an impact on which types are allowed on intersections. We present a type system that prevents intersection types that are not disjoint, as well as an algorithmic specifications to determine whether two types are disjoint for all three variants.
不相交相交类型
Dunfield展示了一个简单类型的核心微积分与交集类型和合并算子能够捕捉各种编程语言的特点。虽然他的演算是类型安全的,但并不连贯:同一表达式的不同推导可以细化为求值不同的表达式。缺乏一致性是在编程语言实现中采用他的核心演算的一个重要缺点,因为编程语言的语义变得依赖于实现。本文给出了λ_i:一个具有交类型形式和归并算子的相干类型安全演算。连贯性是通过确保交叉类型是不相交的,并且程序被充分注释以避免类型歧义来实现的。我们提出了一个不相交的定义,当a和B的两个类型的集合是a和B的共同超型时,两个类型a和B才不相交。我们研究了λ_i的三种不同的变体,具有三种不相交的变体。在最简单的变体中,它不允许有任何的类型,如果两个类型完全没有共同的超类型,那么它们就是不相交的。另外两个变体引入了类型,并改进了不相交的概念,当只有公共超类型的集合是类顶的时,允许两个类型不相交。这两种类型的变量之间的区别在于对类顶类型的定义,这对交集上允许的类型有影响。我们提出了一种类型系统,可以防止不相交的交叉类型,以及一种算法规范,以确定所有三种变体的两个类型是否不相交。
本文章由计算机程序翻译,如有差异,请以英文原文为准。
求助全文
约1分钟内获得全文 求助全文
来源期刊
自引率
0.00%
发文量
0
×
引用
GB/T 7714-2015
复制
MLA
复制
APA
复制
导出至
BibTeX EndNote RefMan NoteFirst NoteExpress
×
提示
您的信息不完整,为了账户安全,请先补充。
现在去补充
×
提示
您因"违规操作"
具体请查看互助需知
我知道了
×
提示
确定
请完成安全验证×
copy
已复制链接
快去分享给好友吧!
我知道了
右上角分享
点击右上角分享
0
联系我们:info@booksci.cn Book学术提供免费学术资源搜索服务,方便国内外学者检索中英文文献。致力于提供最便捷和优质的服务体验。 Copyright © 2023 布克学术 All rights reserved.
京ICP备2023020795号-1
ghs 京公网安备 11010802042870号
Book学术文献互助
Book学术文献互助群
群 号:481959085
Book学术官方微信