File Download

There are no files associated with this item.

  Links for fulltext
     (May Require Subscription)
Supplementary

Conference Paper: Disjoint intersection types

TitleDisjoint intersection types
Authors
KeywordsType System
Intersection Types
Issue Date2016
PublisherAssociation for Computing Machinery (ACM).
Citation
Proceedings of the 21st ACM SIGPLAN International Conference on Functional Programming (ICFP 2016), Nara, Japan, 18-24 September 2016, p. 364-377 How to Cite?
AbstractDunfield 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.
Persistent Identifierhttp://hdl.handle.net/10722/301421
ISBN

 

DC FieldValueLanguage
dc.contributor.authorDos Santos Oliveira, BC-
dc.contributor.authorShi, Z-
dc.contributor.authorBI, X-
dc.date.accessioned2021-07-27T08:10:49Z-
dc.date.available2021-07-27T08:10:49Z-
dc.date.issued2016-
dc.identifier.citationProceedings of the 21st ACM SIGPLAN International Conference on Functional Programming (ICFP 2016), Nara, Japan, 18-24 September 2016, p. 364-377-
dc.identifier.isbn9781450342193-
dc.identifier.urihttp://hdl.handle.net/10722/301421-
dc.description.abstractDunfield 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.-
dc.languageeng-
dc.publisherAssociation for Computing Machinery (ACM).-
dc.relation.ispartofProceedings of the 21st ACM SIGPLAN International Conference on Functional Programming-
dc.subjectType System-
dc.subjectIntersection Types-
dc.titleDisjoint intersection types-
dc.typeConference_Paper-
dc.identifier.emailDos Santos Oliveira, BC: bruno@cs.hku.hk-
dc.identifier.authorityDos Santos Oliveira, BC=rp01786-
dc.description.naturelink_to_subscribed_fulltext-
dc.identifier.doi10.1145/2951913.2951945-
dc.identifier.hkuros323711-
dc.identifier.spage364-
dc.identifier.epage377-
dc.publisher.placeNew York, NY-

Export via OAI-PMH Interface in XML Formats


OR


Export to Other Non-XML Formats