Semantic subtyping and XML programming

MPRI

Theory and practice of XML processing programming languages Giuseppe Castagna CNRS Universit´ e Paris 7 - Denis Diderot

MPRI Lectures on Theory of Subtyping

logoP7

G. Castagna: Theory and practice of XML processing languages

1/110

MPRI

Outline of the lecture 1

XML Programming in CDuce

2

Theoretical Foundations

3

Polymorphic Subtyping

4

Polymorphic Language

logoP7


2/110

MPRI



XML Regular Expression Types and Patterns XML Programming in CDuce Tools on top of CDuce

2

Theoretical Foundations

3


4


logoP7


2/110

MPRI




2

Theoretical Foundations Semantic subtyping Subtyping algorithms CDuce functional core

3


4


logoP7


2/110

MPRI




2


3

Polymorphic Subtyping Current status Semantic solution Subtyping algorithm

4


logoP7


2/110

MPRI




2


3

Polymorphic Subtyping Current status Semantic solution Subtyping algorithm

4

Polymorphic Language Motivating example Formal setting Explicit substitutions Inference System Efficient implementation G. Castagna: Theory and practice of XML processing languages

logoP7

2/110

1. Introduction

2. Regexp types/patterns

3. XML Programming in

CDuce

3. Properties

4. Toolkit

MPRI

PART 1: XML PROGRAMMING IN CDUCE

logoP7

Part 1: XML Programming in

CDuce


3/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Programming with XML

Level 0: textual representation of XML documents AWK, sed, Perl

logoP7


CDuce


4/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI



Level 1: abstract view provided by a parser SAX, DOM, . . .

logoP7


CDuce


4/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI




Level 2: untyped XML-specific languages XSLT, XPath

logoP7


CDuce


4/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI





Level 3: XML types taken seriously (aka: related work) XDuce, Xtatic XQuery Cω (Microsoft) ... logoP7


CDuce


4/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI





Level 3: XML types taken seriously (aka: related work) XDuce, Xtatic XQuery Cω (Microsoft) ... logoP7


CDuce


4/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Presentation of CDuce

logoP7


CDuce


5/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Presentation of CDuce Features: Oriented to XML processing Type centric General-purpose features Very efficient

logoP7


CDuce


5/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Presentation of CDuce Features: Oriented to XML processing Type centric General-purpose features Very efficient Intended use: Small “adapters” between different XML applications Larger applications that use XML Web development Web services

logoP7


CDuce


5/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Presentation of CDuce Features: Oriented to XML processing Type centric General-purpose features Very efficient Intended use: Small “adapters” between different XML applications Larger applications that use XML Web development Web services Status: Public release available (0.5.3) in all major Linux distributions. Integration with standards Internally: Unicode, XML, Namespaces, XML Schema Externally: DTD, WSDL

Some tools: graphical queries, code embedding (à la php) logoP7


CDuce


5/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Presentation of CDuce Features: Oriented to XML processing Type centric General-purpose features Very efficient Intended use: Small “adapters” between different XML applications Larger applications that use XML Web development Web services Status: Public release available (0.5.3) in all major Linux distributions. Integration with standards Internally: Unicode, XML, Namespaces, XML Schema Externally: DTD, WSDL

Some tools: graphical queries, code embedding (à la php) logoP7

Used both for teaching and in production code. Part 1: XML Programming in

CDuce


5/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Types, Types, Types!!!

Types are pervasive in CDuce:

logoP7


CDuce


6/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


Types are pervasive in CDuce: Static validation E.g.: does the transformation produce valid XHTML ?

logoP7


CDuce


6/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI



Type-driven programming semantics At the basis of the definition of patterns Dynamic dispatch Overloaded functions

logoP7


CDuce


6/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI



Type-driven programming semantics At the basis of the definition of patterns Dynamic dispatch Overloaded functions

Type-driven compilation Optimizations made possible by static types Avoids unnecessary and redundant tests at runtime Allows a more declarative style logoP7


CDuce


6/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Regular Expression Types and Patterns for XML

logoP7


CDuce


7/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Types & patterns: the functional languages perspective Types are sets of values Values are decomposed by patterns Patterns are roughly values with capture variables

logoP7


CDuce


8/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Types & patterns: the functional languages perspective Types are sets of values Values are decomposed by patterns Patterns are roughly values with capture variables Instead of let x = fst(e) in let y = snd(e) in (y,x)

logoP7


CDuce


8/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Types & patterns: the functional languages perspective Types are sets of values Values are decomposed by patterns Patterns are roughly values with capture variables Instead of let x = fst(e) in let y = snd(e) in (y,x) with pattern one can write let (x,y) = e in (y,x)

logoP7


CDuce


8/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Types & patterns: the functional languages perspective Types are sets of values Values are decomposed by patterns Patterns are roughly values with capture variables Instead of let x = fst(e) in let y = snd(e) in (y,x) with pattern one can write let (x,y) = e in (y,x) which is syntactic sugar for match e with (x,y) -> (y,x) logoP7


CDuce


8/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Types & patterns: the functional languages perspective Types are sets of values Values are decomposed by patterns Patterns are roughly values with capture variables Instead of let x = fst(e) in let y = snd(e) in (y,x) with pattern one can write let (x,y) = e in (y,x) which is syntactic sugar for match e with (x,y) -> (y,x) “match” is more interesting than “let”, since it can test |”-separated patterns. several “| Part 1: XML Programming in

CDuce


logoP7

8/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Example: tail-recursive version of length for lists: type List = (Any,List) | ‘nil

logoP7


CDuce


9/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Example: tail-recursive version of length for lists: type List = (Any,List) | ‘nil fun length (x:(List,Int)) : Int = match x with | (‘nil , n) -> n | (( ,t), n) -> length(t,n+1)

logoP7


CDuce


9/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Example: tail-recursive version of length for lists: type List = (Any,List) | ‘nil fun length (x:(List,Int)) : Int = match x with | (‘nil , n) -> n | (( ,t), n) -> length(t,n+1)

logoP7


CDuce


9/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Example: tail-recursive version of length for lists: type List = (Any,List) | ‘nil fun length (x:(List,Int)) : Int = match x with | (‘nil , n) -> n | (( ,t), n) -> length(t,n+1) So patterns are values with capture variables, wildcards, constants.

logoP7


CDuce


9/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Example: tail-recursive version of length for lists: type List = (Any,List) | ‘nil fun length (x:(List,Int)) : Int = match x with | (‘nil , n ) -> n t), n ) -> length(t,n+1) | (( ,t So patterns are values with capture variables, wildcards, constants.

logoP7


CDuce


9/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Example: tail-recursive version of length for lists: type List = (Any,List) | ‘nil fun length (x:(List,Int)) : Int = match x with | (‘nil , n) -> n | (( ,t), n) -> length(t,n+1) So patterns are values with capture variables, wildcards, constants.

logoP7


CDuce


9/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Example: tail-recursive version of length for lists: type List = (Any,List) | ‘nil fun length (x:(List,Int)) : Int = match x with ‘nil , n) -> n | (‘nil | (( ,t), n) -> length(t,n+1) So patterns are values with capture variables, wildcards, constants.

logoP7


CDuce


9/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Example: tail-recursive version of length for lists: type List = (Any,List) | ‘nil fun length (x:(List,Int)) : Int = match x with | (‘nil , n) -> n | (( ,t), n) -> length(t,n+1) So patterns are values with capture variables, wildcards, constants. But if we:

logoP7


CDuce


9/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Example: tail-recursive version of length for lists: type List = (Any,List) | ‘nil fun length (x:(List,Int)) : Int = match x with | (‘nil , n) -> n | (( ,t), n) -> length(t,n+1) So patterns are values with capture variables, wildcards, constants. But if we: 1

use for types the same constructors as for values (e.g. (s,t) instead of s × t)

logoP7


CDuce


9/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Example: tail-recursive version of length for lists: type List = (Any,List) | ‘nil (List,Int) fun length (x:(List,Int) (List,Int)) : Int = match x with | (‘nil , n) -> n | (( ,t), n) -> length(t,n+1) So patterns are values with capture variables, wildcards, constants. But if we: 1

use for types the same constructors as for values (e.g. (s,t) instead of s × t)

logoP7


CDuce


9/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


2

use for types the same constructors as for values (e.g. (s,t) instead of s × t) use values to denote singleton types (e.g. ‘nil in the list type);

logoP7


CDuce


9/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


2


logoP7


CDuce


9/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


2

3


consider the wildcard “ ” as synonym of Any logoP7


CDuce


9/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Example: tail-recursive version of length for lists: Any type List = (Any Any,List) | ‘nil fun length (x:(List,Int)) : Int = match x with | (‘nil , n) -> n | (( ,t), n) -> length(t,n+1) So patterns are values with capture variables, wildcards, constants. But if we: 1

2

3


consider the wildcard “ ” as synonym of Any logoP7


CDuce


9/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Example: tail-recursive version of length for lists: type List = (Any,List) | ‘nil fun length (x:(List,Int)) : Int = match x with | (‘nil , n) -> n | (( ,t), n) -> length(t,n+1) So patterns are values with capture variables, wildcards, constants. But if we: Key ideafor behind patterns 1 use typesregular the same constructors as for values (e.g. (s,t) instead of s × t) 2

use values to denote singleton types Patterns are types with capture variables (e.g. ‘nil in the list type);

3

considerDefine the wildcard “ ” as synonym Any types: patterns come foroffree.


CDuce


logoP7

9/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI



3



CDuce


logoP7

9/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI



3



CDuce


logoP7

9/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Which types should we start from? Patterns are tightly connected to boolean type constructors, that is unions (|), intersections (&) and differences (\\):

logoP7


CDuce


10/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


t = {v | v value of type t} and * p++ = {v | v matches pattern p} logoP7


CDuce


10/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI




CDuce


10/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Which types should we start from? Patterns are tightly connected to boolean type constructors, that is unions (|), intersections (&) and differences (\\): Boolean operators are needed to type pattern matching: match e with p1 -> e1 | p2 -> e2 - To infer the type t1 of e1 we need t& * p1+ (where e : t); - To infer the type t2 of e2 we need (t \ * p1+ )& * p2+ ; - The type of the match is t1 |t2 .



CDuce


10/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI




CDuce


10/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI




CDuce


10/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI




CDuce


10/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI




CDuce


10/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Which types should we start from? Patterns are tightly connected to boolean type constructors, that is unions (|), intersections (&) and differences (\\): Boolean operators are needed to type pattern matching: match e with p1 -> e1 | p2 -> e2 & * p1 + - To infer the type t1 of e1 we need t& (where e : t); & * p2+ ; - To infer the type t2 of e2 we need (t \ * p1+ )& - The type of the match is t1| t2 .



CDuce


10/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Which types should we start from? Patterns are tightly connected to boolean type constructors, that is unions (|), intersections (&) and differences (\\): Boolean operators are needed to type pattern matching: match e with p1 -> e1 | p2 -> e2 - To infer the type t1 of e1 we need t& * p1+ (where e : t); - To infer the type t2 of e2 we need (t \ * p1+ )& * p2+ ; - The type of the match is t1 |t2 . Boolean type constructors are useful for programming: map catalogue with x :: (Car & (Guaranteed|(Any\Used)) -> x Select in catalogue all cars that if used then are guaranteed.

logoP7


CDuce


10/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Which types should we start from? Patterns are tightly connected to boolean type constructors, that is unions (|), intersections (&) and differences (\\): Boolean operators are needed to type pattern matching: match e with p1 -> e1 | p2 -> e2 - To infer the type t1 of e1 we need t& * p1+ (where e : t); - To infer the type t2 of e2 we need (t \ * p1+ )& * p2+ ; - The type of the match is t1 |t2 . Boolean type constructors are useful for programming: map catalogue with x :: (Car & (Guaranteed|(Any\Used)) -> x Select in catalogue all cars that if used then are guaranteed. Roadmap to extend it to XML: logoP7


CDuce


10/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Which types should we start from? Patterns are tightly connected to boolean type constructors, that is unions (|), intersections (&) and differences (\\): Boolean operators are needed to type pattern matching: match e with p1 -> e1 | p2 -> e2 - To infer the type t1 of e1 we need t& * p1+ (where e : t); - To infer the type t2 of e2 we need (t \ * p1+ )& * p2+ ; - The type of the match is t1 |t2 . Boolean type constructors are useful for programming: map catalogue with x :: (Car & (Guaranteed|(Any\Used)) -> x Select in catalogue all cars that if used then are guaranteed. Roadmap to extend it to XML: 1

Define types for XML documents, logoP7


CDuce


10/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Which types should we start from? Patterns are tightly connected to boolean type constructors, that is unions (|), intersections (&) and differences (\\): Boolean operators are needed to type pattern matching: match e with p1 -> e1 | p2 -> e2 - To infer the type t1 of e1 we need t& * p1+ (where e : t); - To infer the type t2 of e2 we need (t \ * p1+ )& * p2+ ; - The type of the match is t1 |t2 . Boolean type constructors are useful for programming: map catalogue with x :: (Car & (Guaranteed|(Any\Used)) -> x Select in catalogue all cars that if used then are guaranteed. Roadmap to extend it to XML: 1 2

Define types for XML documents, Add boolean type constructors,


CDuce


logoP7

10/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Which types should we start from? Patterns are tightly connected to boolean type constructors, that is unions (|), intersections (&) and differences (\\): Boolean operators are needed to type pattern matching: match e with p1 -> e1 | p2 -> e2 - To infer the type t1 of e1 we need t& * p1+ (where e : t); - To infer the type t2 of e2 we need (t \ * p1+ )& * p2+ ; - The type of the match is t1 |t2 . Boolean type constructors are useful for programming: map catalogue with x :: (Car & (Guaranteed|(Any\Used)) -> x Select in catalogue all cars that if used then are guaranteed. Roadmap to extend it to XML: 1 2 3

Define types for XML documents, Add boolean type constructors, Define patterns as types with capture variables


CDuce


logoP7

10/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

XML syntax type Bib = [Book Book] [’Object-Oriented Programming’] [’Castagna’] [’Giuseppe’] ] [’56’] ’Bikh¨ auser’ ] [’Regexp Types for XML’] [’Hosoya’] [’Haruo’] ] ’UoT’ ] logoP7 ] Part 1: XML Programming in

CDuce


11/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

XML syntax type Bib = [Book Book] [ [’Object-Oriented Programming’] [ [’Castagna’] [’Giuseppe’] ] [’56’] ’Bikh¨ auser’ ] [ [’Regexp Types for XML’] [’Hosoya’] [’Haruo’] ] ’UoT’ ] ] Part 1: XML Programming in

CDuce


logoP7

11/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

XML syntax type Bib = [Book Book] [ [’Object-Oriented Programming’] [ [’Castagna’] [’Giuseppe’] ] [’56’] ’Bikh¨ auser’ ] [ [’Regexp Types for XML’] [’Hosoya’] [’Haruo’] ] ’UoT’ ] ] Part 1: XML Programming in

CDuce


logoP7

11/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

XML syntax type Bib = [Book Book] [ [ [PCDATA] [PCDATA] ] [PCDATA] PCDATA ] [ [PCDATA] [PCDATA] [PCDATA] ] PCDATA ] ] Part 1: XML Programming in

CDuce

String = [PCDATA] = [Char*]


logoP7

11/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

XML syntax type Bib = [Book Book] type Book = [ Title (Author+ | Editor+) Price? PCDATA] type Author = [Last First] type Editor = [Last First] type Title = [PCDATA] type Last = [PCDATA] type First = [PCDATA] type Price = [PCDATA]

This and: singletons, intersections, differences, Empty, and Any. logoP7


CDuce


11/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

XML syntax type Bib = [Book*] type Book = [ Title (Author+ | Editor+) Price? PCDATA] type Author = [Last First] type Editor = [Last First] type Title = [PCDATA] type Last = [PCDATA] type First = [PCDATA] type Price = [PCDATA]



CDuce


11/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI




CDuce


11/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


Kleene star



CDuce


11/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

XML syntax type Bib = [Book*] type Book = [ attribute types Title (Author+ | Editor+) Price? PCDATA] type Author = [Last First] type Editor = [Last First] type Title = [PCDATA] type Last = [PCDATA] type First = [PCDATA] type Price = [PCDATA]



CDuce


11/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

XML syntax type Bib = [Book*] type Book = [ Title nested elements (Author+ | Editor+) Price? PCDATA] type Author = [Last First] type Editor = [Last First] type Title = [PCDATA] type Last = [PCDATA] type First = [PCDATA] type Price = [PCDATA]



CDuce


11/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


unions



CDuce


11/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

XML syntax type Bib = [Book*] type Book = [ Title (Author+ | Editor+) Price? optional elems PCDATA] type Author = [Last First] type Editor = [Last First] type Title = [PCDATA] type Last = [PCDATA] type First = [PCDATA] type Price = [PCDATA]



CDuce


11/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

XML syntax type Bib = [Book*] type Book = [ Title (Author+ | Editor+) Price? PCDATA] mixed content type Author = [Last First] type Editor = [Last First] type Title = [PCDATA] type Last = [PCDATA] type First = [PCDATA] type Price = [PCDATA]



CDuce


11/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI




CDuce


11/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Patterns Patterns = Types + Capture variables

logoP7


CDuce


12/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Patterns Patterns = Types + Capture variables

type Bib = [Book*] type Book = [Title Author+ Publisher] type Publisher = String

logoP7


CDuce


12/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Patterns

TYPES


PATTERNS

Patterns = Types + Capture variables

match bibs with [x::Book*] -> x

logoP7


CDuce


12/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Patterns

TYPES


PATTERNS



The pattern binds x to the sequence of all books in the bibliography

logoP7


CDuce


12/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Patterns

TYPES


PATTERNS



logoP7


CDuce


12/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Patterns

TYPES


PATTERNS



Returns the content of bibs.

logoP7


CDuce


12/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Patterns

TYPES


PATTERNS


match bibs with [( x::

| y::

)*] -> x@y

logoP7


CDuce


12/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Patterns

TYPES


PATTERNS



| y::

)*] -> x@y

Binds x to the sequence of all this year’s books, and y to all the other books.

logoP7


CDuce


12/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Patterns

TYPES


PATTERNS



| y::

)*] -> x@y

logoP7


CDuce


12/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Patterns

TYPES


PATTERNS



| y::

)*] -> x@y

Returns the concatenation (i.e., “@”) of the two captured sequences

logoP7


CDuce


12/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Patterns

TYPES


PATTERNS


match bibs with [(x::[

* Publisher\"ACM"] | )*] -> x

logoP7


CDuce


12/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Patterns

TYPES


PATTERNS




Binds x to the sequence of books published in 1990 from publishers others than “ACM” and discards all the others.

logoP7


CDuce


12/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Patterns

TYPES


PATTERNS




logoP7


CDuce


12/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Patterns

TYPES


PATTERNS




Returns all the captured books

logoP7


CDuce


12/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Patterns

TYPES


PATTERNS




Returns all the captured books Exact type inference: E.g.: if we match the pattern [(x::Int| )*] against an expression of type [Int* String Int] the type deduced for x is [Int+] logoP7


CDuce


12/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Patterns

TYPES


PATTERNS




Returns all the captured books Exact type inference: *] against an expression E.g.: if we match the pattern [(x::Int| )* +] of type [Int* String Int] the type deduced for x is [Int+ logoP7


CDuce


12/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

XML-programming in CDuce

logoP7


CDuce


13/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Functions: basic usage type type type type

Program = [ Day* ] Day = [ Invited? Talk+ ] Invited = [ Title Author+ ] Talk = [ Title Author+ ]

logoP7


CDuce


14/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI



Extract subsequences (union polymorphism) fun (Invited|Talk -> [Author+]) < >[ Title x::Author* ] -> x

logoP7


CDuce


14/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI




Extract subsequences of non-consecutive elements: fun ([(Invited|Talk|Event)*] -> ([Invited*], [Talk*])) [ (i::Invited | t::Talk | )* ] -> (i,t)

logoP7


CDuce


14/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI




Extract subsequences of non-consecutive elements: fun ([(Invited|Talk|Event)*] -> ([Invited*], [Talk*])) [ (i::Invited | t::Talk | )* ] -> (i,t)

Perl-like string processing (String = [Char*]) fun parse email (String -> (String,String)) | [ local:: * ’@’ domain:: * ] -> (local,domain) | -> raise "Invalid email address"


CDuce


logoP7

14/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Functions: advanced usage type type type type


logoP7


CDuce


15/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI



Functions can be higher-order and overloaded let patch program (p :[Program], f :(Invited -> Invited) & (Talk -> Talk)):[Program] = xtransform p with (Invited | Talk) & x -> [ (f x) ]

logoP7


CDuce


15/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI




logoP7


CDuce


15/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI




logoP7


CDuce


15/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI




Higher-order, overloading, subtyping provide name/code sharing...

logoP7


CDuce


15/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI




Higher-order, overloading, subtyping provide name/code sharing... let first author ([Program] -> [Program]; Invited -> Invited; Talk -> Talk) | [ Program ] & p -> patch program (p,first author) | [ t a * ] -> [ t a ] | [ t a * ] -> [ t a ] logoP7


CDuce


15/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI




Higher-order, overloading, subtyping provide name/code sharing... let first author ([Program] -> [Program]; Invited -> Invited; Talk -> Talk) | [ Program ] & p -> patch program (p,first author) | [ t a * ] -> [ t a ] | [ t a * ] -> [ t a ] logoP7


CDuce


15/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI




Higher-order, overloading, subtyping provide name/code sharing... let first author ([Program] -> [Program]; Invited -> Invited; Talk -> Talk) | [ Program ] & p -> patch program (p,first author) | [ t a * ] -> [ t a ] | [ t a * ] -> [ t a ]

Even more compact: replace the last two branches with:

logoP7

[ t a * ] -> [ t a ] Part 1: XML Programming in

CDuce


15/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI




Higher-order, overloading, subtyping provide name/code sharing... let first author ([Program] -> [Program]; Invited -> Invited; Talk -> Talk) | [ Program ] & p -> patch program (p,first author) | [ t a * ] -> [ t a ] | [ t a * ] -> [ t a ]

Even more compact: replace the last two branches with:

logoP7

[ t a * ] -> [ t a ] Part 1: XML Programming in

CDuce


15/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

. . . it is all syntactic sugar! Types →t | t ∨ t | t ∧ t | ¬t | Any t ::= Int | v | (t, t) | t→

logoP7


CDuce


16/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

. . . it is all syntactic sugar! Types →t | t ∨ t | t ∧ t | ¬t | Any t ::= Int | v | (t, t) | t→ Patterns p ::= t | x | (p, p) | p ∨ p | p ∧ p

logoP7


CDuce


16/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

. . . it is all syntactic sugar! Types →t | t ∨ t | t ∧ t | ¬t | Any t ::= Int | v | (t, t) | t→ Patterns p ::= t | x | (p, p) | p ∨ p | p ∧ p Example: type Book = [Title (Author+|Editor+) Price?]

logoP7


CDuce


16/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

. . . it is all syntactic sugar! Types →t | t ∨ t | t ∧ t | ¬t | Any t ::= Int | v | (t, t) | t→ Patterns p ::= t | x | (p, p) | p ∨ p | p ∧ p Example: type Book = [Title (Author+|Editor+) Price?] encoded as Book = (‘book, (Title, X ∨ Y )) X = (Author, X ∨ (Price, ‘nil) ∨ ‘nil) Y = (Editor, Y ∨ (Price, ‘nil) ∨ ‘nil) Part 1: XML Programming in

CDuce


logoP7

16/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Some reasons to consider regular expression types and patterns

logoP7


CDuce


17/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Some good reasons to consider regexp patterns/types

Theoretical reason: very compact

logoP7


CDuce


18/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


Theoretical reason: very compact (6= simple)

logoP7


CDuce


18/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


Theoretical reason: very compact (6= simple) Nine practical reasons:

logoP7


CDuce


18/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


Theoretical reason: very compact (6= simple) Nine practical reasons: 1 2 3 4 5 6 7 8 9

Classic usage Informative error messages Error mining Efficient execution Compact programs Logical optimisation of pattern-based queries Pattern matches as building blocks for iterators Type/pattern-based data pruning for memory usage optimisation Type-based query optimisation logoP7


CDuce


18/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


Theoretical reason: very compact (6= simple) Nine practical reasons: 1 2 3 4 5 6 7 8 9

Classic usage Informative error messages ← Error mining Efficient execution← Compact programs Logical optimisation of pattern-based queries Pattern matches as building blocks for iterators Type/pattern-based data pruning for memory usage optimisation Type-based query optimisation logoP7


CDuce


18/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

2. Informative error messages In case of error return a sample value in the difference of the inferred type and the expected one

logoP7


CDuce


19/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

2. Informative error messages In case of error return a sample value in the difference of the inferred type and the expected one List of books of a given year, stripped of the Editors and Price

logoP7


CDuce


19/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

2. Informative error messages In case of error return a sample value in the difference of the inferred type and the expected one type Book = [Title (Author+|Editor+) Price?]

List of books of a given year, stripped of the Editors and Price fun onlyAuthors (year:Int,books:[Book*]):[Book*] = select (t@a) from [(t::Title | a::Author | )+] in books where int of(y) = year

logoP7


CDuce


19/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI



Returns the following error message: Error at chars 81-83: select (t@a) from This expression should have type: [ Title (Editor+|Author+) Price? ] but its inferred type is: [ Title Author+ | Title ] which is not a subtype, as shown by the sample: [ [ ] ] logoP7


CDuce


19/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI





CDuce


19/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI





CDuce


19/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI





CDuce


19/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI





CDuce


19/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


List of books of a given year, stripped of the Editors and Price fun onlyAuthors (year:Int,books:[Book*]):[Book*] = select (t@a) from + * ] in books [ t::Title a::Author+ where int of(y) = year



CDuce


19/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

5. Efficient execution Use static type information to perform an optimal set of tests

logoP7


CDuce


20/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


Idea: if types tell you that something cannot happen, don’t test it.

logoP7


CDuce


20/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


Idea: if types tell you that something cannot happen, don’t test it. type A = [A*] type B = [B*] fun check(x : A|B) = match x with

A

-> 1 | B -> 0

fun check(x : A|B) = match x with -> 1 |

-> 0

logoP7


CDuce


20/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI



A

-> 1 | B -> 0


-> 0

logoP7


CDuce


20/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI



A

-> 1 | B -> 0


-> 0

logoP7


CDuce


20/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI



A

-> 1 | B -> 0


-> 0

logoP7


CDuce


20/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI



A

-> 1 | B -> 0


-> 0

No backtracking.

logoP7


CDuce


20/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI



A

-> 1 | B -> 0


-> 0

No backtracking. Whole parts of the matched data are not checked logoP7


CDuce


20/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI



A

-> 1 | B -> 0


-> 0

No backtracking. Whole parts of the matched data are not checked Computing the optimal solution requires to fully exploit inter- logoP7 sections and differences of types Part 1: XML Programming in

CDuce


20/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI



A

-> 1 | B -> 0


-> 0

No backtracking. Whole parts of the matched data are not checked Specific kind of push-down tree automata Part 1: XML Programming in

CDuce


logoP7

20/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

On top of CDuce

logoP7


CDuce


21/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Full integration with OCaml Embedding of CDuce code in XML documents Graphical queries Security (control flow analysis) Web-services

logoP7


CDuce


22/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Full integration with OCaml Embedding of CDuce code in XML documents Graphical queries Security (control flow analysis) Web-services

logoP7


CDuce


22/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

CDuce↔OCaml Integration A CDuce application that requires OCaml code

logoP7


CDuce


23/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

CDuce↔OCaml Integration A CDuce application that requires OCaml code Reuse existing librairies Abstract data structures : hash tables, sets, ... Numerical computations, system calls Bindings to C libraries : databases, networks, ...

logoP7


CDuce


23/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


Implement complex algorithms

logoP7


CDuce


23/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


Implement complex algorithms An OCaml application that requires CDuce code

logoP7


CDuce


23/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


Implement complex algorithms An OCaml application that requires CDuce code CDuce used as an XML input/output/transformation layer

logoP7


CDuce


23/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


Implement complex algorithms An OCaml application that requires CDuce code CDuce used as an XML input/output/transformation layer Configuration files XML serialization of datas XHTML code production logoP7


CDuce


23/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI


Implement complex algorithms An OCaml application that requires CDuce code CDuce used as an XML input/output/transformation layer Configuration files XML serialization of datas XHTML code production

Need to seamlessly call OCaml code in CDuce and viceversa Part 1: XML Programming in

CDuce


logoP7

23/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Main Challenges

logoP7


CDuce


24/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Main Challenges

1

Seamless integration:

logoP7


CDuce


24/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Main Challenges

1

Seamless integration: No explicit conversion function in programs:

logoP7


CDuce


24/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Main Challenges

1

Seamless integration: No explicit conversion function in programs: the compiler performs the conversions

logoP7


CDuce


24/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Main Challenges

1


2

Type safety:

logoP7


CDuce


24/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Main Challenges

1


2

Type safety: No explicit type cast in programs:

logoP7


CDuce


24/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Main Challenges

1


2

Type safety: No explicit type cast in programs: the standard type-checkers ensure type safety

logoP7


CDuce


24/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Main Challenges

1


2

Type safety: No explicit type cast in programs: the standard type-checkers ensure type safety

What we need: A mapping between OCaml and CDuce types and values logoP7


CDuce


24/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

How to integrate the two type systems? The translation can go just one way: OCaml → CDuce

logoP7


CDuce


25/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

How to integrate the two type systems? The translation can go just one way: OCaml → CDuce ⊕ CDuce uses (semantic) subtyping; OCaml does not

logoP7


CDuce


25/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

How to integrate the two type systems? The translation can go just one way: OCaml → CDuce ⊕ CDuce uses (semantic) subtyping; OCaml does not If we translate CDuce types into OCaml ones : - soundness requires the translation to be monotone; - no subtyping in Ocaml implies a constant translation;

logoP7


CDuce


25/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

How to integrate the two type systems? The translation can go just one way: OCaml → CDuce ⊕ CDuce uses (semantic) subtyping; OCaml does not If we translate CDuce types into OCaml ones : - soundness requires the translation to be monotone; - no subtyping in Ocaml implies a constant translation; ⇒ CDuce typing would be lost.

logoP7


CDuce


25/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

How to integrate the two type systems? The translation can go just one way: OCaml → CDuce ⊕ CDuce uses (semantic) subtyping; OCaml does not If we translate CDuce types into OCaml ones : - soundness requires the translation to be monotone; - no subtyping in Ocaml implies a constant translation; ⇒ CDuce typing would be lost. ⊕ CDuce has unions, intersections, differences, heterogeneous lists; OCaml does not

logoP7


CDuce


25/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

How to integrate the two type systems? The translation can go just one way: OCaml → CDuce ⊕ CDuce uses (semantic) subtyping; OCaml does not If we translate CDuce types into OCaml ones : - soundness requires the translation to be monotone; - no subtyping in Ocaml implies a constant translation; ⇒ CDuce typing would be lost. ⊕ CDuce has unions, intersections, differences, heterogeneous lists; OCaml does not ⇒ OCaml types are not enough to translate CDuce types.

logoP7


CDuce


25/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

How to integrate the two type systems? The translation can go just one way: OCaml → CDuce ⊕ CDuce uses (semantic) subtyping; OCaml does not If we translate CDuce types into OCaml ones : - soundness requires the translation to be monotone; - no subtyping in Ocaml implies a constant translation; ⇒ CDuce typing would be lost. ⊕ CDuce has unions, intersections, differences, heterogeneous lists; OCaml does not ⇒ OCaml types are not enough to translate CDuce types. OCaml supports type polymorphism; CDuce does not. logoP7


CDuce


25/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

How to integrate the two type systems? The translation can go just one way: OCaml → CDuce ⊕ CDuce uses (semantic) subtyping; OCaml does not If we translate CDuce types into OCaml ones : - soundness requires the translation to be monotone; - no subtyping in Ocaml implies a constant translation; ⇒ CDuce typing would be lost. ⊕ CDuce has unions, intersections, differences, heterogeneous lists; OCaml does not ⇒ OCaml types are not enough to translate CDuce types. OCaml supports type polymorphism; CDuce does not.

⇒ Polymorphic OCaml libraries/functions must be first instantied to be used in CDuce


CDuce


logoP7

25/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

In practice 1

Define a mapping T from OCaml types to CDuce types.

logoP7


CDuce


26/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

In practice 1

Define a mapping T from OCaml types to CDuce types. t (OCaml) int string t1 ∗ t2 t1 → t2 t list t array t option t ref A1 of t1 | . . . | An of tn {l1 = t1 ; . . . ; ln = tn }

T(t) (CDuce) min int- -max int Latin1 (T(t1 ), T(t2 )) T(t1 ) → T(t2 ) [T(t)∗] [T(t)∗] [T(t)?] ref T(t) (‘A1 , T(t1 )) | . . . | (‘An , T(tn )) {l1 = T(t1 ); . . . ; ln = T(tn )}

logoP7


CDuce


26/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

In practice 1


2


Define a retraction pair between OCaml and CDuce values. logoP7


CDuce


26/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

In practice 1


2


Define a retraction pair between OCaml and CDuce values. ocaml2cduce: t → T(t) cduce2ocaml: T(t) → t


CDuce


logoP7

26/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Calling OCaml from CDuce Easy Use M.f to call the function f exported by the OCaml module M

logoP7


CDuce


27/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Calling OCaml from CDuce Easy Use M.f to call the function f exported by the OCaml module M The CDuce compiler checks type soundness and then

logoP7


CDuce


27/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Calling OCaml from CDuce Easy Use M.f to call the function f exported by the OCaml module M The CDuce compiler checks type soundness and then - applies cduce2ocaml to the arguments of the call

logoP7


CDuce


27/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Calling OCaml from CDuce Easy Use M.f to call the function f exported by the OCaml module M The CDuce compiler checks type soundness and then - applies cduce2ocaml to the arguments of the call - calls the OCaml function

logoP7


CDuce


27/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Calling OCaml from CDuce Easy Use M.f to call the function f exported by the OCaml module M The CDuce compiler checks type soundness and then - applies cduce2ocaml to the arguments of the call - calls the OCaml function - applies ocaml2cduce to the result of the call

logoP7


CDuce


27/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Calling OCaml from CDuce Easy Use M.f to call the function f exported by the OCaml module M The CDuce compiler checks type soundness and then - applies cduce2ocaml to the arguments of the call - calls the OCaml function - applies ocaml2cduce to the result of the call Example: use ocaml-mysql library in CDuce let db = Mysql.connect Mysql.defaults;; match Mysql.list dbs db ‘None [] with | (‘Some,l) -> print [ ’Databases: ’ !(string of l) ’\ n’ ] | ‘None -> [];; logoP7


CDuce


27/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Calling CDuce from OCaml Needs little work Compile a CDuce module as an OCaml binary module by providing a OCaml (.mli) interface. Use it as a standard Ocaml module.

logoP7


CDuce


28/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Calling CDuce from OCaml Needs little work Compile a CDuce module as an OCaml binary module by providing a OCaml (.mli) interface. Use it as a standard Ocaml module. The CDuce compiler:

logoP7


CDuce


28/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Calling CDuce from OCaml Needs little work Compile a CDuce module as an OCaml binary module by providing a OCaml (.mli) interface. Use it as a standard Ocaml module. The CDuce compiler: 1 Checks that if val f :t in the .mli file, then the CDuce type of f is a subtype of T(t)

logoP7


CDuce


28/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Calling CDuce from OCaml Needs little work Compile a CDuce module as an OCaml binary module by providing a OCaml (.mli) interface. Use it as a standard Ocaml module. The CDuce compiler: 1 Checks that if val f :t in the .mli file, then the CDuce type of f is a subtype of T(t) 2 Produces the OCaml glue code to export CDuce values as OCaml ones and bind OCaml values in the CDuce module.

logoP7


CDuce


28/110

1. Introduction



CDuce

3. Properties

4. Toolkit

MPRI

Calling CDuce from OCaml Needs little work Compile a CDuce module as an OCaml binary module by providing a OCaml (.mli) interface. Use it as a standard Ocaml module. The CDuce compiler: 1 Checks that if val f :t in the .mli file, then the CDuce type of f is a subtype of T(t) 2 Produces the OCaml glue code to export CDuce values as OCaml ones and bind OCaml values in the CDuce module. Example: use CDuce to compute a factorial: (* File cdnum.mli: *) val fact: Big int.big int -> Big int.big int (* File cdnum.cd: *) let aux ((Int,Int) -> Int) | (x, 0 | 1) -> x | (x, n) -> aux (x * n, n - 1) logoP7

let fact (x : Int) : Int = aux(1,x) Part 1: XML Programming in

CDuce


28/110

1. Introduction –

2. Semantic subtyping –

3. Algorithms –

4. Language –

6. Recap –

MPRI

PART 2: THEORETICAL FOUNDATIONS

logoP7

Part 2: Theoretical Foundations


29/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Goal The goal is to show how to take your favourite type constructors

logoP7



30/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Goal The goal is to show how to take your favourite type constructors × , → , {. . . }, chan(), . . .

logoP7



30/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Goal The goal is to show how to take your favourite type constructors × , → , {. . . }, chan(), . . . and add boolean combinators: ∨, ∧, ¬ so that they behave set-theoretically w.r.t. ≤

logoP7



30/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Goal The goal is to show how to take your favourite type constructors × , → , {. . . }, chan(), . . . and add boolean combinators: ∨, ∧, ¬ so that they behave set-theoretically w.r.t. ≤ WHY? Short answer: YOU JUST SAW IT! Recap: - to encode XML types - to define XML patterns - to precisely type pattern matching Part 2: Theoretical Foundations


logoP7

30/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

In details ×t | t→ →t t ::= B | t×

logoP7



31/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

In details ∨t | t∧ ∧t | ¬t | 0 | 1 ×t | t→ →t | t∨ t ::= B | t×

logoP7



31/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

In details ∨t | t∧ ∧t | ¬t | 0 | 1 ×t | t→ →t | t∨ t ::= B | t× Handling subtyping without combinators is easy: constructors do not mix,

logoP7



31/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

In details ∨t | t∧ ∧t | ¬t | 0 | 1 ×t | t→ →t | t∨ t ::= B | t× Handling subtyping without combinators is easy: constructors do not mix, e.g. : s2 ≤ s1 t1 ≤ t2 s1 → t1 ≤ s2 → t2

logoP7



31/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

In details ∨t | t∧ ∧t | ¬t | 0 | 1 ×t | t→ →t | t∨ t ::= B | t× Handling subtyping without combinators is easy: constructors do not mix, e.g. : s2 ≤ s1 t1 ≤ t2 s1 → t1 ≤ s2 → t2 With combinators is much harder: combinators distribute over constructors,

logoP7



31/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

In details ∨t | t∧ ∧t | ¬t | 0 | 1 ×t | t→ →t | t∨ t ::= B | t× Handling subtyping without combinators is easy: constructors do not mix, e.g. : s2 ≤ s1 t1 ≤ t2 s1 → t1 ≤ s2 → t2 With combinators is much harder: combinators distribute over constructors, e.g. (s1∨ s2 ) → t

R

∧(s2 → t) (s1 → t)∧

logoP7



31/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

In details ∨t | t∧ ∧t | ¬t | 0 | 1 ×t | t→ →t | t∨ t ::= B | t× Handling subtyping without combinators is easy: constructors do not mix, e.g. : s2 ≤ s1 t1 ≤ t2 s1 → t1 ≤ s2 → t2 With combinators is much harder: combinators distribute over constructors, e.g. (s1∨ s2 ) → t

R

∧(s2 → t) (s1 → t)∧

MAIN IDEA Instead of defining the subtyping relation so that it conforms to the semantic of types, define the semantics of types and derive the logoP7 subtyping relation. Part 2: Theoretical Foundations


31/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

In details ∨t | t∧ ∧t | ¬t | 0 | 1 ×t | t→ →t | t∨ t ::= B | t× Not a particularly new idea. Many attempts (e.g. Aiken&Wimmers, Damm,. . . , Hosoya&Pierce).



31/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

In details ∨t | t∧ ∧t | ¬t | 0 | 1 ×t | t→ →t | t∨ t ::= B | t× Not a particularly new idea. Many attempts (e.g. Aiken&Wimmers, Damm,. . . , Hosoya&Pierce). None fully satisfactory. (no negation, or no function types, or restrictions on unions and intersections, . . . )



31/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

In details ∨t | t∧ ∧t | ¬t | 0 | 1 ×t | t→ →t | t∨ t ::= B | t× Not a particularly new idea. Many attempts (e.g. Aiken&Wimmers, Damm,. . . , Hosoya&Pierce). None fully satisfactory. (no negation, or no function types, or restrictions on unions and intersections, . . . ) Starting point of what follows: the approach of Hosoya&Pierce. MAIN IDEA Instead of defining the subtyping relation so that it conforms to the semantic of types, define the semantics of types and derive the logoP7 subtyping relation. Part 2: Theoretical Foundations


31/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Semantic subtyping

logoP7



32/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Semantic subtyping

logoP7



33/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Semantic subtyping 1

Define a set-theoretic semantics of the types: J K : Types −→ P(D)

logoP7



33/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI



2

Define the subtyping relation as follows: s≤t

def

⇐⇒ JsK ⊆ JtK

logoP7



33/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI



2


def

⇐⇒ JsK ⊆ JtK

KEY OBSERVATION 1: The model of types may be independent from a model of terms

logoP7



33/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI



2


def

⇐⇒ JsK ⊆ JtK

KEY OBSERVATION 1: The model of types may be independent from a model of terms Hosoya and Pierce use the model of values: JtKV = {v | ` v : t} Ok because the only values of XDuce are XML documents (no first-class functions) Part 2: Theoretical Foundations


logoP7

33/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Step 1 : Model Define when J K : Types −→ P(D) yields a set-theoretic model.

logoP7



34/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Step 1 : Model Define when J K : Types −→ P(D) yields a set-theoretic model. Easy for the combinators: Jt1∨t2 K = Jt1 K ∪ Jt2 K Jt1∧ t2 K = Jt1 K ∩ Jt2 K ¬tK J¬ = D\JtK J0K = ∅ J1K = D

logoP7



34/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Step 1 : Model Define when J K : Types −→ P(D) yields a set-theoretic model. Easy for the combinators: Jt1∨t2 K = Jt1 K ∪ Jt2 K Jt1∧ t2 K = Jt1 K ∩ Jt2 K ¬tK J¬ = D\JtK J0K = ∅ J1K = D Hard for constructors: Jt1× t2 K = Jt1→ t2 K =

logoP7



34/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Step 1 : Model Define when J K : Types −→ P(D) yields a set-theoretic model. Easy for the combinators: Jt1∨t2 K = Jt1 K ∪ Jt2 K Jt1∧ t2 K = Jt1 K ∩ Jt2 K ¬tK J¬ = D\JtK J0K = ∅ J1K = D Hard for constructors: Jt1× t2 K = Jt1 K × Jt2 K Jt1→ t2 K =

logoP7



34/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Step 1 : Model Define when J K : Types −→ P(D) yields a set-theoretic model. Easy for the combinators: Jt1∨t2 K = Jt1 K ∪ Jt2 K Jt1∧ t2 K = Jt1 K ∩ Jt2 K ¬tK J¬ = D\JtK J0K = ∅ J1K = D Hard for constructors: Jt1× t2 K = Jt1 K × Jt2 K Jt1→ t2 K = ???

logoP7



34/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Step 1 : Model Define when J K : Types −→ P(D) yields a set-theoretic model. Easy for the combinators: Jt1∨t2 K = Jt1 K ∪ Jt2 K Jt1∧ t2 K = Jt1 K ∩ Jt2 K ¬tK J¬ = D\JtK J0K = ∅ J1K = D Hard for constructors: Jt1× t2 K = Jt1 K × Jt2 K Jt1→ t2 K = ???

Think semantically! logoP7



34/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Intuition →sK = ??? (×JsK)Jt→

logoP7



35/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Intuition →sK = {functions from JtK to JsK} (×JsK)Jt→

logoP7



35/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Intuition →sK = {f ⊆ D2 | ∀(d1 , d2 ) ∈ f . d1 ∈ JtK ⇒ d2 ∈ JsK} (×JsK)Jt→

logoP7



35/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Intuition →sK = P(JtK × JsK) (×JsK)Jt→

def

( X = complement of X )

logoP7



35/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


(∗)

Impossible since it requires P(D2 ) ⊆ D

logoP7



35/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


(∗)

KEY OBSERVATION 2: We need the model to state how types are related rather than what the types are

logoP7



35/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


(∗)

KEY OBSERVATION 2: We need the model to state how types are related

Accept every J K that behaves w.r.t. ⊆ as if equation (∗) held,

logoP7



35/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


(∗)

KEY OBSERVATION 2: We need the model to

Accept every J K that behaves w.r.t. ⊆ as if equation (∗) held, namely Jt1→ s1 K ⊆ Jt2→ s2 K

⇐⇒

P(Jt1 K × Js1 K) ⊆ P(Jt2 K × Js2 K) logoP7



35/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


(∗)

KEY OBSERVATION 2: We need the model to

Accept every J K that behaves w.r.t. ⊆ as if equation (∗) held, namely Jt1→ s1 K ⊆ Jt2→ s2 K

⇐⇒

P(Jt1 K × Js1 K) ⊆ P(Jt2 K × Js2 K)

and similarly for any boolean combination of arrow types. Part 2: Theoretical Foundations


logoP7

35/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Technically . . . 1

Take J K : Types → P(D) such that Jt1∨ t2 K = Jt1 K ∪ Jt2 K Jt1∧ t2 K = Jt1 K ∩ Jt2 K J0K = ∅ J1K = D ¬ J¬ tK = J1K\JtK

logoP7



36/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Technically . . . 1

Take J K : Types → P(D) such that Jt1∨ t2 K = Jt1 K ∪ Jt2 K Jt1∧ t2 K = Jt1 K ∩ Jt2 K J0K = ∅ J1K = D ¬ J¬ tK = J1K\JtK [connective semantics]

logoP7



36/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Technically . . . 1

2

Take J K : Types → P(D) such that Jt1∨ t2 K = Jt1 K ∪ Jt2 K Jt1∧ t2 K = Jt1 K ∩ Jt2 K J0K = ∅ J1K = D ¬ J¬ tK = J1K\JtK [connective semantics] 2 Define E( ) : Types → P(D + P(D2 )) as follows def E(t1× t2 ) = Jt1 K × Jt2 K ⊆ D2 E(t1→ t2 )

def

=

E(t1∨ t2 )

def

E(0)

def

¬t) E(¬

def

= =

=

P(Jt1 K × Jt2 K) ⊆ P(D2 ) E(t1 ) ∪ E(t2 ) ∅

E(1)\E(t)

E(t1∧ t2 ) E(1)

def

=

def

=

E(t1 ) ∩ E(t2 ) D2 + P(D2 )

logoP7



36/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Technically . . . 1

2


def

=

E(t1∨ t2 )

def

E(0)

def

¬t) E(¬

def

= =

=

P(Jt1 K × Jt2 K) ⊆ P(D2 ) E(t1 ) ∪ E(t2 ) ∅

E(1)\E(t)

E(t1∧ t2 ) E(1)

def

=

def

=

E(t1 ) ∩ E(t2 ) D2 + P(D2 )

[constructor semantics]

logoP7



36/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Technically . . . 1

2

3


def

=

E(t1∨ t2 )

def

E(0)

def

¬t) E(¬

def

= =

=

P(Jt1 K × Jt2 K) ⊆ P(D2 ) E(t1 ) ∪ E(t2 ) ∅

E(t1∧ t2 ) E(1)

E(1)\E(t)

def

=

def

=

E(t1 ) ∩ E(t2 ) D2 + P(D2 )

[constructor semantics] Model: Instead of requiring JtK = E(t), accept J K if JtK = ∅ ⇐⇒ E(t) = ∅



logoP7

36/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Technically . . . 1

2

3


def

=

E(t1∨ t2 )

def

E(0)

def

¬t) E(¬

def

= =

=

P(Jt1 K × Jt2 K) ⊆ P(D2 ) E(t1 ) ∪ E(t2 ) ∅

E(t1∧ t2 ) E(1)

def

=

def

=

E(1)\E(t)

E(t1 ) ∩ E(t2 ) D2 + P(D2 )

[constructor semantics] Model: Instead of requiring JtK = E(t), accept J K if JtK = ∅ ⇐⇒ E(t) = ∅

logoP7

(which is equivalent to JsK ⊆ JtK ⇐⇒ E(s) ⊆ E(t)) Part 2: Theoretical Foundations


36/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

The main intuition To characterize ≤ all is needed is the test of emptyness

logoP7



37/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

The main intuition To characterize ≤ all is needed is the test of emptyness ∧¬ tK = ∅ Indeed: s ≤ t ⇔ JsK ⊆ JtK ⇔ JsK ∩ JtK = ∅ ⇔ Js∧

logoP7



37/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

The main intuition To characterize ≤ all is needed is the test of emptyness ∧¬ tK = ∅ Indeed: s ≤ t ⇔ JsK ⊆ JtK ⇔ JsK ∩ JtK = ∅ ⇔ Js∧ Instead of JtK = E(t), the weaker JtK = ∅ ⇔ E(t) = ∅ suffices for ≤.

logoP7



37/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

The main intuition To characterize ≤ all is needed is the test of emptyness ∧¬ tK = ∅ Indeed: s ≤ t ⇔ JsK ⊆ JtK ⇔ JsK ∩ JtK = ∅ ⇔ Js∧ Instead of JtK = E(t), the weaker JtK = ∅ ⇔ E(t) = ∅ suffices for ≤. J K and E( ) must have the same zeros

logoP7



37/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

The main intuition To characterize ≤ all is needed is the test of emptyness ∧¬ tK = ∅ Indeed: s ≤ t ⇔ JsK ⊆ JtK ⇔ JsK ∩ JtK = ∅ ⇔ Js∧ Instead of JtK = E(t), the weaker JtK = ∅ ⇔ E(t) = ∅ suffices for ≤. J K and E( ) must have the same zeros We relaxed our requirement but . . . DOES A MODEL EXIST? Is it possible to define J K : Types → P(D) that satisfies the model conditions, in particular a JK such that JtK = ∅ ⇔ E(t) = ∅? logoP7



37/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

The main intuition To characterize ≤ all is needed is the test of emptyness ∧¬ tK = ∅ Indeed: s ≤ t ⇔ JsK ⊆ JtK ⇔ JsK ∩ JtK = ∅ ⇔ Js∧ Instead of JtK = E(t), the weaker JtK = ∅ ⇔ E(t) = ∅ suffices for ≤. J K and E( ) must have the same zeros We relaxed our requirement but . . . DOES A MODEL EXIST? Is it possible to define J K : Types → P(D) that satisfies the model conditions, in particular a JK such that JtK = ∅ ⇔ E(t) = ∅? YES: an example within two slides logoP7



37/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

The role of E() E() characterizes the behavior of types (for what it concerns ≤ one can consider JtK = E(t)): it depends on the language the types are intended for.

logoP7



38/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

The role of E() E() characterizes the behavior of types (for what it concerns ≤ one can consider JtK = E(t)): it depends on the language the types are intended for. Variations are possible. Our choice E(t1→ t2 ) = P(Jt1 K × Jt2 K) accounts for languages that are:

logoP7



38/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

The role of E() E() characterizes the behavior of types (for what it concerns ≤ one can consider JtK = E(t)): it depends on the language the types are intended for. Variations are possible. Our choice E(t1→ t2 ) = P(Jt1 K × Jt2 K) accounts for languages that are: 1

Non-deterministic: Admits functions in which (d, d1 ) and (d, d2 ) with d1 6= d2 .

logoP7



38/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


2

Non-deterministic: Admits functions in which (d, d1 ) and (d, d2 ) with d1 6= d2 . Non-terminating : →sK may be not total on JtK. a function in Jt→

logoP7



38/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


2

Non-deterministic: Admits functions in which (d, d1 ) and (d, d2 ) with d1 6= d2 . Non-terminating : →sK may be not total on JtK.E.g. a function in Jt→ →0K = functions diverging on t Jt→

logoP7



38/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


2

3

Non-deterministic: Admits functions in which (d, d1 ) and (d, d2 ) with d1 6= d2 . Non-terminating : →sK may be not total on JtK.E.g. a function in Jt→ →0K = functions diverging on t Jt→

Overloaded: →(s1∧s2 )K J(t1∨t2 )→


∧(t2→s2 )K J(t1→s1 )∧


logoP7

38/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Closing the circle 1

Take any model (B, JKB ) to bootstrap the definition.

logoP7



39/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Closing the circle 1 2

Take any model (B, JKB ) to bootstrap the definition. Define

s ≤B t

⇐⇒

JsKB ⊆ JtKB

logoP7



39/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


3


s ≤B t

⇐⇒

JsKB ⊆ JtKB

Take any “appropriate” language L and use ≤B to type it Γ `B e : t

logoP7



39/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


3


s ≤B t

⇐⇒

JsKB ⊆ JtKB


4

Define a new interpretation JtKV = {v ∈ V | `B v : t} and s ≤V t ⇐⇒ JsKV ⊆ JtKV

logoP7



39/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


3


s ≤B t

⇐⇒

JsKB ⊆ JtKB


4

5

Define a new interpretation JtKV = {v ∈ V | `B v : t} and s ≤V t ⇐⇒ JsKV ⊆ JtKV If L is “appropriate” (`B v : t ⇐⇒ 6`B v : ¬ t) then JKV is a model and s ≤B t ⇐⇒ s ≤V t logoP7



39/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


3


s ≤B t

⇐⇒

JsKB ⊆ JtKB


4

5

Define a new interpretation JtKV = {v ∈ V | `B v : t} and s ≤V t ⇐⇒ JsKV ⊆ JtKV If L is “appropriate” (`B v : t ⇐⇒ 6`B v : ¬ t) then JKV is a model and s ≤B t ⇐⇒ s ≤V t


The circle is closed

logoP7


39/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Exhibit a model Does a model exists? (i.e. a J K such that JtK = ∅ ⇐⇒ E(t) = ∅)

logoP7



40/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Exhibit a model Does a model exists? (i.e. a J K such that JtK = ∅ ⇐⇒ E(t) = ∅) YES: take (U, J KU ) where

logoP7



40/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Exhibit a model Does a model exists? (i.e. a J K such that JtK = ∅ ⇐⇒ E(t) = ∅) YES: take (U, J KU ) where 1

U least solution of X = X 2 + Pf (X 2 )

logoP7



40/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


U least solution of X = X 2 + Pf (X 2 )

logoP7



40/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


2

U least solution of X = X 2 + Pf (X 2 ) J KU is defined as:

logoP7



40/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


2


J0KU = ∅ J1KU = U ∨tKU = JsKU ∪ JtKU Js∨

¬tKU = U\JtKU J¬ ∧tKU = JsKU ∩ JtKU Js∧

logoP7



40/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


2


J0KU = ∅ J1KU = U ∨tKU = JsKU ∪ JtKU Js∨ ×tKU = JsKU × JtKU Js×


→sKU = Pf (JtKU × JsKU ) Jt→

logoP7



40/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


2





logoP7



40/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


2





It is a model: Pf (JtKU × JsKU ) = ∅ ⇐⇒ P(JtKU × JsKU ) = ∅

logoP7



40/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


2





It is a model: Pf (JtKU × JsKU ) = ∅ ⇐⇒ P(JtKU × JsKU ) = ∅ It is the best model: for any other model J KD t1 ≤D t2


⇒

t1 ≤U t2

logoP7


40/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Subtyping Algorithms.

logoP7



41/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Canonical forms Every (recursive) type ×t | t→ →t | t∨ ∨t | t∧ ∧t | ¬t | 0 | 1 t ::= B | t×

logoP7



42/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Canonical forms Every (recursive) type ×t | t→ →t | t∨ ∨t | t∧ ∧t | ¬t | 0 | 1 t ::= B | t× is equivalent (semantically, w.r.t. ≤) to a type of the form (I omitted base types): _ ^ ^ _ ^ ^ ×t)∧ ∧( ×t))) →t)∧ ∧( →t))) (( s× ¬ (s× (( s→ ¬ (s→

(P,N)∈Π

×t∈P s×

×t∈N s×

(P,N)∈Σ

→t∈P s→

→t∈N s→

logoP7



42/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


(P,N)∈Π 1

×t∈P s×

×t∈N s×

(P,N)∈Σ

→t∈P s→

→t∈N s→

Put it in disjunctive normal form, e.g. ∨(a4∧¬ a5 )∨ ∨(¬ ¬a6∧¬ a7 )∨ ∨(a8∧ a9 ) (a1∧ a2∧¬ a3 )∨

logoP7



42/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


(P,N)∈Π 1

2

×t∈P s×

×t∈N s×

(P,N)∈Σ

→t∈P s→

→t∈N s→

Put it in disjunctive normal form, e.g. ∨(a4∧¬ a5 )∨ ∨(¬ ¬a6∧¬ a7 )∨ ∨(a8∧ a9 ) (a1∧ a2∧¬ a3 )∨ Transform to have only homogeneous intersections, e.g. ∧¬ (s2× t2 )) ∨ (¬ ¬(s3→ t3 )∧ ∧¬ (s4→ t4 )) ∨ (s5× t5 ) ((s1× t1 )∧

logoP7



42/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


(P,N)∈Π 1

2

3

×t∈P s×

×t∈N s×

(P,N)∈Σ

→t∈P s→

→t∈N s→

Put it in disjunctive normal form, e.g. ∨(a4∧¬ a5 )∨ ∨(¬ ¬a6∧¬ a7 )∨ ∨(a8∧ a9 ) (a1∧ a2∧¬ a3 )∨ Transform to have only homogeneous intersections, e.g. ∧¬ (s2× t2 )) ∨ (¬ ¬(s3→ t3 )∧ ∧¬ (s4→ t4 )) ∨ (s5× t5 ) ((s1× t1 )∧ Group negative and positive atoms in the intersections: _ ^ ^ ∧( (( a)∧ ¬ a)) a∈N

logoP7


42/110

(P,N)∈S


a∈P

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Decision procedure s ≤ t?

logoP7



43/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Decision procedure s ≤ t? Recall that: ∧¬ tK = ∅ ⇐⇒ s∧ ∧¬ t = 0 s ≤ t ⇐⇒ JsK ∩ JtK = ∅ ⇐⇒ Js∧

logoP7



43/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Decision procedure s ≤ t? Recall that: ∧¬ tK = ∅ ⇐⇒ s∧ ∧¬ t = 0 s ≤ t ⇐⇒ JsK ∩ JtK = ∅ ⇐⇒ Js∧ 1

∧¬t Consider s∧

logoP7



43/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Decision procedure s ≤ t? Recall that: ∧¬ tK = ∅ ⇐⇒ s∧ ∧¬ t = 0 s ≤ t ⇐⇒ JsK ∩ JtK = ∅ ⇐⇒ Js∧ 1 2


Put it in canonical form _ ^ ^ ×t)∧ ∧( ×t))) (( s× ¬ (s×

×t∈P (P,N)∈Π s×

×t∈N s×

_

((

^

→t)∧ ∧( s→

→t∈P (P,N)∈Σ s→

^

→t))) ¬ (s→

→t∈N s→

logoP7



43/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Decision procedure s ≤ t? Recall that: ∧¬ tK = ∅ ⇐⇒ s∧ ∧¬ t = 0 s ≤ t ⇐⇒ JsK ∩ JtK = ∅ ⇐⇒ Js∧ 1 2


Put it in canonical form _ ^ ^ ×t)∧ ∧( ×t))) (( s× ¬ (s×

×t∈P (P,N)∈Π s× 3

×t∈N s×

_

((

^

→t)∧ ∧( s→

→t∈P (P,N)∈Σ s→

^

→t))) ¬ (s→

→t∈N s→

Decide (coinductively) whether all the intersections occuring above are empty by applying the set theoretic properties stated in the next slide.



logoP7

43/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Subtyping decomposition Decomposition law for products: ^ _ ti × si ≤ tj × sj i∈I

j∈J

    ^ _ _ ^ tj  or  si ≤ sj  ⇐⇒ ∀J 0 ⊆ J.  ti ≤ i∈I

j∈J 0

i∈I

j∈J\J 0

Decomposition law for arrows: ^ _ ti → si ≤ tj → sj i∈I

j∈J

! ⇐⇒ ∃j ∈ J.∀I 0 ⊆ I .


tj ≤

_ i∈I 0

ti



 or I 0 6= I et

^ i∈I \I 0

si ≤ sj 


logoP7

44/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Exercise Using the laws of the previous slide prove the following equivalences: t 1 × s1 ≤ t 2 × s2

⇐⇒

t1 ≤ ∅ or s1 ≤ ∅ or (t1 ≤ t2 and s1 ≤ s2 )

t1→ s1 ≤ t2→ s2

⇐⇒

t2 ≤ ∅ or or (t2 ≤ t1 and s1 ≤ s2 )

logoP7



45/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Application to a language.

logoP7



46/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Language

e: := | | | | |

x µf (s1→ t1 ;...;sn→ tn ) (x).e e1 e2 (e1 ,e2 ) πi (e) (x = e ∈ t)??e1 :e2

variable abstraction, n ≥ 1 application pair projection, i = 1, 2 binding type case

logoP7



47/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Typing Γ ` e : s ≤B t (subsumption) Γè:t

logoP7



48/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Typing Γ ` e : s ≤B t (subsumption) Γè:t

logoP7



48/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Typing Γ ` e : s ≤B t (subsumption) Γè:t (∀i)

Γ, (f : s1→ t1∧ . . . ∧ sn→ tn ), (x : si ) ` e : ti

Γ ` µf (s1→ t1 ;...;sn→ tn ) (x).e : s1→t1∧ . . . ∧sn →tn

(abstr)

logoP7



48/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Typing Γ ` e : s ≤B t (subsumption) Γè:t Γ, (f : s1→ t1∧ . . . ∧ sn→ tn ), (x : si ) ` e : ti

(∀i)


(abstr)

∧t, s2 ≡ s∧ ∧¬ t) (for s1 ≡ s∧

Γè:s

Γ, (x : s1 ) ` e1 : t1

Γ, (x : s2 ) ` e2 : t2 W (typecase) Γ ` (x = e ∈ t)??e1 :e2 : {i|si 6'0} ti

logoP7



48/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


(∀i)


(abstr)

∧t, s2 ≡ s∧ ∧¬ t) (for s1 ≡ s∧

Γè:s

Γ, (x : s1 ) ` e1 : t1


logoP7



48/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


(∀i)


(abstr)

∧t, s2 ≡ s∧ ∧¬ t) (for s1 ≡ s∧

Γè:s

Γ, (x : s1 ) ` e1 : t1


Consider: →Int;Bool→ →Bool) µf(Int→ (x).(y = x ∈ Int)??(y + 1):not(y )

logoP7


48/110


1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Reduction

(µf (...) (x).e)v → e[x/v , (µf (...) (x).e)/f ] (x = v ∈ t)??e1 :e2 → e1 [x/v ] (x = v ∈ t)??e1 :e2 → e2 [x/v ]

if v ∈ JtK if v ∈ 6 JtK

logoP7



49/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Reduction



where v ::= µf (...) (x).e | (v ,v )

logoP7



49/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Reduction



where v ::= µf (...) (x).e | (v ,v ) And we have s ≤B t

⇐⇒

s ≤V t

logoP7



49/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Reduction



where v ::= µf (...) (x).e | (v ,v ) And we have s ≤B t

⇐⇒

s ≤V t

The circle is closed logoP7



49/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Why does it work? s ≤B t

⇐⇒

s ≤V t

(1)

Equation (1) (actually, ⇒) states that the language is quite rich, since there always exists a value to separate two distinct types; i.e. its set of values is a model of types with “enough points”

logoP7



50/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


⇐⇒

s ≤V t

(1)

Equation (1) (actually, ⇒) states that the language is quite rich, since there always exists a value to separate two distinct types; i.e. its set of values is a model of types with “enough points” For any model B, s 6≤B t =⇒ there exists v such that ` v : s and 6` v : t

logoP7



50/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


⇐⇒

s ≤V t

(1)

Equation (1) (actually, ⇒) states that the language is quite rich, since there always exists a value to separate two distinct types; i.e. its set of values is a model of types with “enough points” For any model B, s 6≤B t =⇒ there exists v such that ` v : s and 6` v : t In particular, thanks to multiple arrows in λ-abstractions: ^ si → ti 6≤ t i=1..k

then the two types are distinguished by µf (s1→ t1 ;...;sk → tk ) (x).e Part 2: Theoretical Foundations


logoP7

50/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Advantages for the programmer

The programmer does not need to know the gory details. All s/he needs to retain is

logoP7



51/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI


The programmer does not need to know the gory details. All s/he needs to retain is 1

Types are the set of values of that type

logoP7



51/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI




2

Subtyping is set inclusion

logoP7



51/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI




2


Furthermore the property s 6≤ t =⇒ there exists v such that ` v : s and 6` v : t is fundamental for meaningful error messages:

logoP7



51/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI




2


Furthermore the property s 6≤ t =⇒ there exists v such that ` v : s and 6` v : t is fundamental for meaningful error messages: Exibit the v at issue rather than pointing to the failure of some deduction rule. logoP7



51/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

Summary of the theory

logoP7



52/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

La morale de l’histoire est . . . If you have a strong semantic intuition of your favorite language and you want to add set-theoretic ∨ , ∧ , ¬ types then:

logoP7



53/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI

La morale de l’histoire est . . . If you have a strong semantic intuition of your favorite language and you want to add set-theoretic ∨ , ∧ , ¬ types then: 1

Define E( ) for your type constructors so that it matches your semantic intuition

logoP7



53/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI



2

Find a model (any model).

[may be not easy/possible]

logoP7



53/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI



2


3

Use the subtyping relation induced by the model to type your language: if the intuition was right then the set of values is also a model, otherwise tweak it. [may be not easy/possible]


logoP7



53/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI



2


3


4

Use the set-theoretic properties of the model (actually of E( )) to decompose the emptyness test for your type constructors, and hence derive a subtyping algorithm. [may be not easy/possible] logoP7




53/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI



2


3


4

Use the set-theoretic properties of the model (actually of E( )) to decompose the emptyness test for your type constructors, and hence derive a subtyping algorithm. [may be not easy/possible] logoP7




53/110

1. Introduction –


3. Algorithms –

4. Language –

6. Recap –

MPRI



2


3


4

Use the set-theoretic properties of the model (actually of E( )) to decompose the emptyness test for your type constructors, and hence derive a subtyping algorithm. [may be not easy/possible] logoP7 Enjoy.

5




53/110

1. Motivations

2. Current status

2. Semantic solution

3. Examples

4. Algorithm

MPRI

PART 3: POLYMORPHIC SUBTYPING

logoP7

Part 3: Polymorphic subtyping


54/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Goal

logoP7



55/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Goal We want to add Type variables: ×Y → X ) ∧ ((X→ →Y )→ →X→ →Y ) (X× and define for them an intuitive semantics

logoP7



55/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Goal We want to add Type variables: ×Y → X ) ∧ ((X→ →Y )→ →X→ →Y ) (X× and define for them an intuitive semantics WHY?

logoP7



55/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Goal We want to add Type variables: ×Y → X ) ∧ ((X→ →Y )→ →X→ →Y ) (X× and define for them an intuitive semantics WHY? Short answers: Parametric polymorphism is very useful in practice. It covers new needs peculiar to XML processing (eg, SOAP envelopes). It would make the interface with OCaml complete The extension shoud shed new light on the notion of parametricity Part 3: Polymorphic subtyping


logoP7

55/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Concrete answer: an example in web development We need parametric polymorphism to statically type service registration in the Ocsigen web server:

logoP7



56/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Concrete answer: an example in web development We need parametric polymorphism to statically type service registration in the Ocsigen web server: To every page possibly with parameters

corresponds a function that takes the parameters (the query string) and dynamically generates the appropriate Xhtml page: let wikipage (p : WikiParams) : Xhtml = ... type WikiParams = String "raw"|"edit" logoP7 Part 3: Polymorphic subtyping


56/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

The binding between the URL $WEBROOT/w/index and the function wikipage is done by the Ocsigen function register_new_service: register new service(wikipage,"w.index")

logoP7



57/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

The binding between the URL $WEBROOT/w/index and the function wikipage is done by the Ocsigen function register_new_service: register new service(wikipage,"w.index") whenever the page $WEBROOT/w/index is selected, Ocsigen passes the XML encoding of the query string to wikipage and returns its result.

logoP7



57/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

The binding between the URL $WEBROOT/w/index and the function wikipage is done by the Ocsigen function register_new_service: register new service(wikipage,"w.index") whenever the page $WEBROOT/w/index is selected, Ocsigen passes the XML encoding of the query string to wikipage and returns its result. We would like to give register_new_service the type ∀(X ≤ QueryString).(X → Xhtml) × Path → unit

where QueryString is the XML type that includes all query strings and Path specifies the paths of the server.

logoP7



57/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI


where QueryString is the XML type that includes all query strings and Path specifies the paths of the server. Notice We need both higher-order polymorphic functions logoP7



57/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI


where QueryString is the XML type that includes all query strings and Path specifies the paths of the server. Notice We need both higher-order polymorphic functions and bounded quantification Part 3: Polymorphic subtyping


logoP7

57/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

A very hard problem

logoP7



58/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Naive solution ×t | t→ →t t ::= B | t×

logoP7



59/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Naive solution ×t | t→ →t | t∨ ∨t | t∧ ∧t | ¬t | 0 | 1 t ::= B | t×

logoP7



59/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Naive solution ×t | t→ →t | t∨ ∨t | t∧ ∧t | ¬t | 0 | 1 | X t ::= B | t×

logoP7



59/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Naive solution ×t | t→ →t | t∨ ∨t | t∧ ∧t | ¬t | 0 | 1 | X t ::= B | t× Now use the previous relation. This is defined for “ground types” Let σ : Vars → Typesground denote ground substitutions then define: s≤t

def

⇐⇒ ∀σ . sσ ≤ tσ

logoP7



59/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI


def

⇐⇒ ∀σ . sσ ≤ tσ

or equivalently s≤t

def

⇐⇒ ∀σ.JsσK ⊆ JtσK logoP7



59/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI


def

⇐⇒ ∀σ . sσ ≤ tσ

or equivalently s≤t

def

⇐⇒ ∀σ.JsσK ⊆ JtσK

This is a wrong way logoP7



59/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Problems with the naive solution 1

Haruo Hosoya conjectured that deciding ∀σ . sσ ≤ tσ is equivalent to solve Diophantine equations

logoP7



60/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI



2

It breaks parametricity:

logoP7



60/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI



2

It breaks parametricity: ×X ) ≤ (t× ×¬ t) ∨ (X× ×t) (t×

logoP7



60/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI



2


This inclusion holds if and only if t is an atomic type:

logoP7



60/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI



2


This inclusion holds if and only if t is an atomic type: Imagine that t is a singleton or a basic type (both are special cases of atomic types), then for all possible interpretation of X it holds t ≤ X or X ≤ ¬t

logoP7



60/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI



2


This inclusion holds if and only if t is an atomic type: Imagine that t is a singleton or a basic type (both are special cases of atomic types), then for all possible interpretation of X it holds t ≤ X or X ≤ ¬t If X ≤ ¬ t then the left element of the union suffices logoP7



60/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI



2


This inclusion holds if and only if t is an atomic type: Imagine that t is a singleton or a basic type (both are special cases of atomic types), then for all possible interpretation of X it holds t ≤ X or X ≤ ¬t If X ≤ ¬ t then the left element of the union suffices ∨t and, therefore, If t ≤ X , then X = (X \t)∨ ×X ) = (t× ×(X \t))∨ ∨(t× ×t). This union is contained (t× component-wise in the one above. Part 3: Polymorphic subtyping


logoP7

60/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Problems with the naive solution The fact that ×X ) ≤ (t× ×¬ t) ∨ (X× ×t) (t× holds if and only if t is an atomic type is really catastrophic:

logoP7



61/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Problems with the naive solution The fact that ×X ) ≤ (t× ×¬ t) ∨ (X× ×t) (t× holds if and only if t is an atomic type is really catastrophic: It means that to decide subtyping one has to decide atomicity of types which in general is very hard (cf. [Castagna, DeNicola, Varacca TCS 2008])

logoP7



61/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Problems with the naive solution The fact that ×X ) ≤ (t× ×¬ t) ∨ (X× ×t) (t× holds if and only if t is an atomic type is really catastrophic: It means that to decide subtyping one has to decide atomicity of types which in general is very hard (cf. [Castagna, DeNicola, Varacca TCS 2008]) It means that subtyping breaks parametricity since by subsumption we can consider a function generic in its first argument, as one generic on its second argument.

logoP7



61/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Problems with the naive solution The fact that ×X ) ≤ (t× ×¬ t) ∨ (X× ×t) (t× holds if and only if t is an atomic type is really catastrophic: It means that to decide subtyping one has to decide atomicity of types which in general is very hard (cf. [Castagna, DeNicola, Varacca TCS 2008]) It means that subtyping breaks parametricity since by subsumption we can consider a function generic in its first argument, as one generic on its second argument. We can eschew the problem by resorting to syntactic solutions: - Castagna, Frisch, Hosoya [POPL 05] - Vouillon [POPL 06] It implies to give up to the underlying semantic intuition Part 3: Polymorphic subtyping


logoP7

61/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Problems with the naive solution The fact that ×X ) ≤ (t× ×¬ t) ∨ (X× ×t) (t× holds if and only if t is an atomic type is really catastrophic: It means that to decide subtyping one has to decide atomicity of types which in general is very hard (cf. [Castagna, DeNicola, Varacca TCS 2008]) It means that subtyping breaks parametricity since by subsumption we can consider a function generic in its first argument, as one generic on its second argument. We can eschew the problem by resorting to syntactic solutions: - Castagna, Frisch, Hosoya [POPL 05] - Vouillon [POPL 06] It implies to give up to the underlying semantic intuition NO! Part 3: Polymorphic subtyping


logoP7

61/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

A semantic solution Some faint intuition The loss of parametricity is only due to the interpretation of atomic types, all the rest works (more or less) smoothly

logoP7



62/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

A semantic solution Some faint intuition The loss of parametricity is only due to the interpretation of atomic types, all the rest works (more or less) smoothly Indeed it seems that the crux of the problem is that for an atomic type a a ≤ X or X ≤ ¬ a validity can stutter from one formula to another, missing in this way the uniformity typical of parametricity

logoP7



62/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

A semantic solution Some faint intuition The loss of parametricity is only due to the interpretation of atomic types, all the rest works (more or less) smoothly Indeed it seems that the crux of the problem is that for an atomic type a a ≤ X or X ≤ ¬ a validity can stutter from one formula to another, missing in this way the uniformity typical of parametricity If we can give a semantic characterization of models in which this stuttering is absent, then this should yield a subtyping relation that is: Semantic Intuitive for the programmer Decidable Part 3: Polymorphic subtyping


logoP7

62/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Semantic solution

logoP7



63/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

A semantic solution Rough idea We must make atomic types “splittable” so that type variables can range over strict subsets of every type, atomic types included

logoP7



64/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

A semantic solution Rough idea We must make atomic types “splittable” so that type variables can range over strict subsets of every type, atomic types included Since this cannot be done at syntactic level, move to the semantic one and replace ground substitutions by semantic assignements: η : Vars → P(D)

logoP7



64/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

A semantic solution Rough idea We must make atomic types “splittable” so that type variables can range over strict subsets of every type, atomic types included Since this cannot be done at syntactic level, move to the semantic one and replace ground substitutions by semantic assignements: η : Vars → P(D) and now the interpretation function takes an extra parameter J K : Types → P(D)Vars → P(D)

logoP7



64/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

A semantic solution Rough idea We must make atomic types “splittable” so that type variables can range over strict subsets of every type, atomic types included Since this cannot be done at syntactic level, move to the semantic one and replace ground substitutions by semantic assignements: η : Vars → P(D) and now the interpretation function takes an extra parameter J K : Types → P(D)Vars → P(D) with JX Kη = η(X ) Jt1∨ t2 Kη = Jt1 Kη ∪ Jt2 Kη J0Kη = ∅


¬tKη J¬ = D\JtKη Jt1∧ t2 Kη = Jt1 Kη ∩ Jt2 Kη J1Kη = D


logoP7

64/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Subtyping relation

In this framework the natural definition of subtyping is s≤t

def

⇐⇒ ∀η . JsKη ⊆ JtKη

It just remains to find the uniformity condition to recover parametricity.

logoP7



65/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

The magic property Consider only models of semantic subtyping in which the following convexity property holds ∀η.(Jt1 Kη=∅ or Jt2 Kη=∅) ⇐⇒ (∀η.Jt1 Kη=∅) or (∀η.Jt2 Kη=∅)

logoP7



66/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

The magic property Consider only models of semantic subtyping in which the following convexity property holds ∀η.(Jt1 Kη=∅ or Jt2 Kη=∅) ⇐⇒ (∀η.Jt1 Kη=∅) or (∀η.Jt2 Kη=∅) ∧¬ X Kη=∅ or Ja∧ ∧X Kη=∅) holds true It avoids stuttering: (Ja∧ if and only if a is empty.

logoP7



66/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

The magic property Consider only models of semantic subtyping in which the following convexity property holds ∀η.(Jt1 Kη=∅ or Jt2 Kη=∅) ⇐⇒ (∀η.Jt1 Kη=∅) or (∀η.Jt2 Kη=∅) ∧¬ X Kη=∅ or Ja∧ ∧X Kη=∅) holds true It avoids stuttering: (Ja∧ if and only if a is empty. There is a natural model: every model in which all types are interpreted as infinite sets satisfies it (we recover the initial faint intuition).

logoP7



66/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

The magic property Consider only models of semantic subtyping in which the following convexity property holds ∀η.(Jt1 Kη=∅ or Jt2 Kη=∅) ⇐⇒ (∀η.Jt1 Kη=∅) or (∀η.Jt2 Kη=∅) ∧¬ X Kη=∅ or Ja∧ ∧X Kη=∅) holds true It avoids stuttering: (Ja∧ if and only if a is empty. There is a natural model: every model in which all types are interpreted as infinite sets satisfies it (we recover the initial faint intuition). A sound and complete algorithm: the condition gives us exactly the right conditions needed to reuse the subtyping algorithm for ground types (though, decidability is an open problem, yet). logoP7



66/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

The magic property Consider only models of semantic subtyping in which the following convexity property holds ∀η.(Jt1 Kη=∅ or Jt2 Kη=∅) ⇐⇒ (∀η.Jt1 Kη=∅) or (∀η.Jt2 Kη=∅) ∧¬ X Kη=∅ or Ja∧ ∧X Kη=∅) holds true It avoids stuttering: (Ja∧ if and only if a is empty. There is a natural model: every model in which all types are interpreted as infinite sets satisfies it (we recover the initial faint intuition). A sound and complete algorithm: the condition gives us exactly the right conditions needed to reuse the subtyping algorithm for ground types (though, decidability is an open problem, yet). An intuitive relation: the algorithm returns intuitive results (actually, it helps to better understand twisted examples) Part 3: Polymorphic subtyping


logoP7

66/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Examples of subtyping relations

logoP7



67/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Examples We can internalize properties such as: (α → γ) ∧ (β → γ) ∼ α∨β → γ

logoP7



68/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Examples We can internalize properties such as: (α → γ) ∧ (β → γ) ∼ α∨β → γ or distributivity laws: (α∨β × γ) ∼ (α×γ) ∨ (β×γ)

(2)

logoP7



68/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI


(2)

combining them we deduce: (α×γ → δ1 ) ∧ (β×γ → δ2 ) ≤ (α∨β × γ) → δ1 ∨ δ2

logoP7



68/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI


(2)

combining them we deduce: (α×γ → δ1 ) ∧ (β×γ → δ2 ) ≤ (α∨β × γ) → δ1 ∨ δ2 We can prove relevant relations on infinite types. Consider generic lists: α list = µx.(α×x) ∨ nil Part 3: Polymorphic subtyping


logoP7

68/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

It contains both the α-lists with an even number of elements µx.(α×(α×x)) ∨ nil ≤ µx.(α×x) ∨ nil and the α-lists with an odd number of elements µx.(α×(α×x)) ∨ (α×nil) ≤ µx.(α×x) ∨ nil

logoP7



69/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

It contains both the α-lists with an even number of elements µx.(α×(α×x)) ∨ nil ≤ µx.(α×x) ∨ nil and the α-lists with an odd number of elements µx.(α×(α×x)) ∨ (α×nil) ≤ µx.(α×x) ∨ nil and it is itself contained in the union of the two, that is: α list ∼ (µx.(α × (α × x)) ∨ nil) ∨ (µx.(α × (α × x)) ∨ (α × nil))

logoP7



69/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

It contains both the α-lists with an even number of elements µx.(α×(α×x)) ∨ nil ≤ µx.(α×x) ∨ nil and the α-lists with an odd number of elements µx.(α×(α×x)) ∨ (α×nil) ≤ µx.(α×x) ∨ nil and it is itself contained in the union of the two, that is: α list ∼ (µx.(α × (α × x)) ∨ nil) ∨ (µx.(α × (α × x)) ∨ (α × nil))

And we can prove far more complicated relations (see later). logoP7



69/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Subtyping algorithm

logoP7



70/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Subtyping Algorithm Step 1: Transform the subtyping problem into an emptiness decision problem: t1 ≤ t2 ⇐⇒ ∀η.Jt1 Kη ⊆ Jt2 Kη ⇐⇒ ∀η.Jt1 ∧¬t2 Kη=∅ ⇐⇒ t1 ∧¬t2 ≤ 0

logoP7



71/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Subtyping Algorithm Step 1: Transform the subtyping problem into an emptiness decision problem: t1 ≤ t2 ⇐⇒ ∀η.Jt1 Kη ⊆ Jt2 Kη ⇐⇒ ∀η.Jt1 ∧¬t2 Kη=∅ ⇐⇒ t1 ∧¬t2 ≤ 0 Step 2: Put the type whose emptiness is to be decided in disjunctive normal form. _^ ìj i∈I j∈J

where a ::= b | t × t | t → t | 0 | 1 | α and ` ::= a | ¬a

logoP7



71/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Subtyping Algorithm Step 1: Transform the subtyping problem into an emptiness decision problem: t1 ≤ t2 ⇐⇒ ∀η.Jt1 Kη ⊆ Jt2 Kη ⇐⇒ ∀η.Jt1 ∧¬t2 Kη=∅ ⇐⇒ t1 ∧¬t2 ≤ 0 Step 2: Put the type whose emptiness is to be decided in disjunctive normal form. _^ ìj i∈I j∈J

where a ::= b | t × t | t → t | 0 | 1 | α and ` ::= a | ¬a Step 3: Simplify mixed intersections: Consider each summand of the union: cases such as t1×t2 ∧ t1 →t2 or t1×t2 ∧ ¬(t1 →t2 ) are straightforward. ^ ^ ^ ^ Solve: ai ¬aj0 αh ¬βk i∈I

j∈J

h∈H

k∈K

logoP7

where all a are of the same kind. Part 3: Polymorphic subtyping


71/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Step 4: Eliminate toplevel negative variables., ∀η.JtKη = ∅ ⇐⇒ ∀η.Jt{¬α/α}Kη = ∅ so replace ¬βk for βk (forall k ∈ K ) ^ ^ ^ Solve: ai ¬aj0 αh i∈I

j∈J

h∈H

logoP7



72/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Step 4: Eliminate toplevel negative variables., ∀η.JtKη = ∅ ⇐⇒ ∀η.Jt{¬α/α}Kη = ∅ so replace ¬βk for βk (forall k ∈ K ) ^ ^ ^ Solve: ai ¬aj0 αh i∈I

j∈J

Step 5: Eliminate toplevel variables. ^ ^ t1×t2 αh t1×t2 ∈P

h∈H

holds if and only if ^ ^ t1 σ × t2 σ γh1 × γh2 t1×t2 ∈P

h∈H

where σ = {(γh1 ×γh2 ) ∨ αh /αh }h∈H Part 3: Polymorphic subtyping

h∈H

≤

_

t10×t20

t10×t20 ∈N

≤

_

t10 σ × t20 σ

t10×t20 ∈N

(similarly for arrows)


logoP7

72/110

1. Motivations

2. Current status


3. Examples

4. Algorithm

MPRI

Step 6: Eliminate toplevel constructors, memoize, and recurse. Thanks to convexity and the product decomposition rules ^ _ t1×t2 ≤ t10×t20 (3) t10×t20 ∈N

t1×t2 ∈P

is equivalent to  ∀N 0 ⊆N. 

 ^

t1 ≤

_

t10  or 

t1×t2 ∈P t10×t20 ∈N 0



 ^

t2 ≤

t1×t2 ∈P

_

t20 

t10×t20 ∈N\N 0

(similarly for arrows) logoP7



73/110

1. Motivating example 2. Formal setting – 3. Explicit substitutions – 4. Inference system – 5. Evaluation – 6. Conclusion – MPRI

PART 4: POLYMORPHIC LANGUAGE

logoP7

Part 4: Polymorphic Language


74/110


Motivating example

logoP7



75/110


A motivating example in Haskell

[no XML]

α → β ) → [α α] → [β β] map :: (α map f l = case l of | [] -> [] | (x : xs) -> (f x : map f xs)

logoP7



76/110


A motivating example in Haskell

[no XML]

α → β ) → [α α] → [β β] map :: (α map f l = case l of | [] -> [] | (x : xs) -> (f x : map f xs) α\ Int) → (α α\ Int)) even :: (Int→ Bool) ∧ ((α even x = case x of | Int -> (x ‘mod‘ 2) == 0 | _ -> x

logoP7



76/110


A motivating example in Haskell (almost)

[no XML]

α → β ) → [α α] → [β β] map :: (α map f l = case l of | [] -> [] | (x : xs) -> (f x : map f xs) α\ Int) → (α α\ Int)) even :: (Int→ Bool) ∧ ((α even x = case x of | Int -> (x ‘mod‘ 2) == 0 | _ -> x

logoP7



76/110



[no XML]

α → β ) → [α α] → [β β] map :: (α map f l = case l of | [] -> [] | (x : xs) -> (f x : map f xs) α\ Int) → (α α\ Int)) even :: (Int→ Bool) ∧ ((α even x = case x of | Int -> (x ‘mod‘ 2) == 0 | _ -> x Expression: if the argument is an integer then return the Boolean expression otherwise return the argument

logoP7



76/110



[no XML]

α → β ) → [α α] → [β β] map :: (α map f l = case l of | [] -> [] | (x : xs) -> (f x : map f xs) α\ Int) → (α α\ Int)) even :: (Int→ Bool) ∧ ((α even x = case x of | Int -> (x ‘mod‘ 2) == 0 | _ -> x Expression: if the argument is an integer then return the Boolean expression otherwise return the argument Type: when applied to an Int it returns a Bool; when applied to an argument that is not an Int it returns a result of the same type. logoP7



76/110

Motivating –example 2. setting Formal –setting – 3. Explicit substitutions – 4. Inference – 5. Evaluation 6. Conclusion – MPRI 1.1.Motivations 2. Formal 3. Explicit substitutions – 4. Inference systemsystem – 5. Evaluation – 6. – Conclusion – POPL ’14


[no XML]

α → β) α] β] map map :: :: (α (α ) → [α [α ] → [β [β ] map map f f l l = = case case l l of of | | [] [] -> -> [] [] | | (x (x : : xs) xs) -> -> (f (f x x : : map map f f xs) xs) α\ Int) α\ Int)) even even :: :: (Int→ (Int→ Bool) Bool) ∧ ((α ((α Int) → (α (α Int)) even even x x = = case case x x of of | | Int Int -> -> (x (x ‘mod‘ ‘mod‘ 2) 2) == == 0 0 | _ | _ -> -> x x Expression: if the argument is an integer then return the Boolean expression otherwise return the argument Int it returns a Bool; Bool; when applied Type: when applied to an Int to an argument that is not an Int Int it returns a result of the same type. logoP7

Part 4: Polymorphic Giuseppe Castagna Language

G. Castagna:Functions Theory and practice of XMLTypes processing languages Polymorphic with Set-Theoretic

76/110



[no XML]

α → β) α] β] map map :: :: (α (α ) → [α [α ] → [β [β ] map map f f l l = = case case l l of of | | [] [] -> -> [] [] | | (x (x : : xs) xs) -> -> (f (f x x : : map map f f xs) xs) α\ Int) α\ Int)) even even :: :: (Int→ (Int→ Bool) Bool) ∧ ((α ((α Int) → (α (α Int)) even even x x = = case case x x of of | | Int Int -> -> (x (x ‘mod‘ ‘mod‘ 2) 2) == == 0 0 | _ | _ -> -> x x Expression: if the argument is an integer then return the Boolean expression otherwise return the argument Type: when applied to an Int it returns a Bool; when applied to an argument that is not an Int it returns a result of the same type. logoP7



76/110



[no XML]

α → β) α] β] map map :: :: (α (α ) → [α [α ] → [β [β ] map map f f l l = = case case l l of of | | [] [] -> -> [] [] | | (x (x : : xs) xs) -> -> (f (f x x : : map map f f xs) xs) α\ Int) α\ Int)) even even :: :: (Int→ (Int→ Bool) Bool) ∧ ((α ((α Int) → (α (α Int)) even even x x = = case case x x of of | | Int Int -> -> (x (x ‘mod‘ ‘mod‘ 2) 2) == == 0 0 | _ | _ -> -> x x Expression: if the argument is an integer then return the Boolean expression otherwise return the argument Type: when applied to an Int it returns a Bool; when applied to an argument that is not an Int it returns a result of the same type. logoP7



76/110



[no XML]

α → β ) → [α α] → [β β] map :: (α map f l = case l of | [] -> [] | (x : xs) -> (f x : map f xs) α\ Int) → (α α\ Int)) even :: (Int→ Bool) ∧ ((α even x = case x of | Int -> (x ‘mod‘ 2) == 0 | _ -> x Expression: if the argument is an integer then return the Boolean expression otherwise return the argument Type: when applied to an Int it returns a Bool; when applied to an argument that is not an Int it returns a result of the same type. Typical function used to modify some nodes of an XML tree leaving the others unchanged. Part 4: Polymorphic Language


logoP7

76/110



[no XML]

α → β ) → [α α] → [β β] map :: (α map f l = case l of | [] -> [] | (x : xs) -> (f x : map f xs) α\ Int) → (α α\ Int)) even :: (Int→ Bool) ∧ ((α even x = case x of | Int -> (x ‘mod‘ 2) == 0 | _ -> x Expression: if the argument is an integer then return the Boolean expression otherwise return the argument Type: when applied to an Int it returns a Bool; when applied to an argument that is not an Int it returns a result of the same type. The combination of type-case and intersections yields statically typed dynamic overloading. Part 4: Polymorphic Language


logoP7

76/110



[no XML]

α → β ) → [α α] → [β β] map :: (α map f l = case l of | [] -> [] | (x : xs) -> (f x : map f xs) α\ Int) → (α α\ Int)) even :: (Int→ Bool) ∧ ((α even x = case x of | Int -> (x ‘mod‘ 2) == 0 | _ -> x This example as a yardstick. I want to define a language that: 1

Can define both map and even

logoP7



76/110



[no XML]



2

Can check the types specified in the signature logoP7



76/110



[no XML]



2

Can check the types specified in the signature

3

Can deduce the type of the partial application map even logoP7



76/110



[no XML]



2


3




76/110



[no XML]



2


3




76/110



[no XML]

α → β ) → [α α] → [β β] map :: (α map f l = case l of | [] -> [] | (x : xs) -> (f x : map f xs) α\ Int) → (α α\ Int)) even :: (Int→ Bool) ∧ ((α even x = case x of | Int -> (x ‘mod‘ 2) == 0 | _ -> x We expect map even to have the following type: ( Int list → Bool list ) ∧ int lists are transformed into bool lists ( α\ Int list → α\ Int list ) ∧ lists w/o ints return the same type α\ Int)∨ ∨Bool list ) ints in the arg. are replaced by bools ( α∨ Int list → (α Difficult because of expansion: needs a set of type substitutions — logoP7 rather than just one— to unify the domain and the argument types. Part 4: Polymorphic Language


76/110



[no XML]



76/110



[no XML]



76/110


Formal framework

logoP7



77/110


Formal calculus Exprs

e

Types t

::= x | ee | λ∧i∈I si →ti x.e | e∈t ? e : e →t | t∨ ∨t | t∧ ∧t | ¬t | 0 | 1 | α ::= B | t→

logoP7



78/110



e

Types t


Expressions include:

logoP7



78/110



e

Types t


Expressions include: A type-case: abstracts regular type patterns makes dynamic overloading possible

logoP7



78/110



e

Types t


Expressions include: A type-case: abstracts regular type patterns makes dynamic overloading possible Explicitly-typed functions: Needed by the type-case [e.g. µf .λx.f ∈(1→Int) ? true : 42] More expressive with the result type (parameter type not enough) λ∧i∈I si →ti x.e: well typed if for all i∈I from x : si we can deduce e : tlogoP7 i. Part 4: Polymorphic Language


78/110



e

Types t


Types may be recursive and have a set-theoretic interpretation:

logoP7



78/110



e

Types t


Types may be recursive and have a set-theoretic interpretation: Constructors: JIntK={0, 1, −1, ...}. Js → tK = λ-abstractions that when applied to arguments in JsK return only results in JtK.

logoP7



78/110



e

Types t



Connectives have the corresponding set-theoretic interpretation: ∨tK = JsK ∪ JtK ∧tK = JsK ∩ JtK ¬tK = J1K \ JtK Js∨ Js∧ J¬

logoP7



78/110



e

Types t



Connectives have the corresponding set-theoretic interpretation: ∨tK = JsK ∪ JtK ∧tK = JsK ∩ JtK ¬tK = J1K \ JtK Js∨ Js∧ J¬ Subtyping: it is defined as set-containment:

def

s ≤ t ⇐⇒ JsK ⊆ JtK; logoP7



78/110



e

Types t



Connectives have the corresponding set-theoretic interpretation: ∨tK = JsK ∪ JtK ∧tK = JsK ∩ JtK ¬tK = J1K \ JtK Js∨ Js∧ J¬

Subtyping with type variables: def it is defined as set-containment: s ≤ t ⇐⇒ JsK ⊆ JtK; it is such that forall type-substitutions σ: s ≤ t ⇒ sσ ≤ tσ; logoP7 it is decidable. [ICFP2011].



78/110


Formal calculus: new stuff Exprs

e

Types t


Polymorphic functions.

logoP7



78/110


calculus: new stuff Formal calculus Exprs

e

Types t

::= x | ee | λ∧i∈I si →ti x.e | e∈t ? ?e : :e →t | t∨ ∨t | t∧ ∧t | ¬t | 0 | 1 | α ::= B | t→

Polymorphic functions: The novelty of this work is that type variables can occur in the interfaces.

logoP7



78/110



e

Types t


Polymorphic functions: The novelty of this work is that type variables can occur in the interfaces. λα→α x.x polymorphic identity ∧α→β λ(α→β)∧ x.xx auto-application

logoP7



78/110



e

Types t


Polymorphic functions: The novelty of this work is that type variables can occur in the interfaces. λα→α x.x polymorphic identity ∧α→β λ(α→β)∧ x.xx auto-application Meaning: types obtained by subsumption and by instantiation λα→α x.x : 0 → 1 subsumption λα→α x.x : ¬Int subsumption α→α λ x.x : Int → Int instantiation λα→α x.x : Bool → Bool instantiation logoP7 Part 4: Polymorphic Language


78/110



e

Types t


Problem Define an explicitly typed, polymorphic calculus with intersection types and dynamic type-case

logoP7



78/110



e

Types t



logoP7



78/110



e

Types t



Four simple points to show why dealing with this blend is quite problematic logoP7



78/110


1. Polymorphism needs instantiation:

logoP7



79/110


1. Polymorphism needs instantiation: To apply λα→α x.x to 42 we must use the instance obtained by the type substitution {Int/α}: (λInt→Int x.x)42 we relabel the function by instantiating its interface.

logoP7



79/110


1. Polymorphism needs instantiation: To apply λα→α x.x to 42 we must use the instance obtained by the type substitution {Int/α}: (λInt→Int x.x)42 we relabel the function by instantiating its interface. 2. Type-case needs explicit relabeling: (λα→α→α x.λα→α y .x)42 ∈ Int→Int (λα→α→α x.λα→α y .x)true 6∈ Int→Int Interfaces determine λ-abstractions’s types

; λInt→Int y .42 ; λBool→Bool y .true [intrinsic semantics]

logoP7



79/110




logoP7



79/110




3. Relabeling must be applied also on function bodies:

logoP7



79/110




3. Relabeling must be applied also on function bodies: A “daffy” definition of identity: (λα→α x.(λα→α y .x)x)

logoP7



79/110




3. Relabeling must be applied also on function bodies: A “daffy” definition of identity: (λα→α x.(λα→α y .x)x) To apply it to 42, relabeling the outer λ by {Int/α} does not suffice: (λα→α y .42)42 is not well typed. The body must be relabeled as well, by applying the {Int/α} yielding: (λInt→Int y .42)42



logoP7

79/110


4. Relabeling the body is not always straightforward:

logoP7



80/110


4. Relabeling the body is not always straightforward: 1

More than one type-substitution needed

2

Relabeling depends on the dynamic type of the argument

logoP7



80/110




2


logoP7



80/110




2


The identity function λα→α x.x has both these types: (Int→Int) ∧ (Bool→Bool)

logoP7



80/110




2


The identity function λα→α x.x has both these types: (Int→Int) ∧ (Bool→Bool) So it has their intersection.

logoP7



80/110




2


The identity function λα→α x.x has both these types: (Int→Int) ∧ (Bool→Bool) So it has their intersection. We can feed the identity to a function which expects argument of that type. But how do we relabel it?

logoP7



80/110




2


The identity function λα→α x.x has both these types: (Int→Int) ∧ (Bool→Bool) So it has their intersection. We can feed the identity to a function which expects argument of that type. But how do we relabel it? Intuitively: apply {Int/α} and {Bool/α} to the interface and replace it by the intersection of the two instances:

logoP7



80/110




2


The identity function λα→α x.x has both these types: (Int→Int) ∧ (Bool→Bool) So it has their intersection. We can feed the identity to a function which expects argument of that type. But how do we relabel it? Intuitively: apply {Int/α} and {Bool/α} to the interface and replace it by the intersection of the two instances: (λα→α x.x)[{Int/α}, {Bool/α}]

;

∧(Bool→Bool) λ(Int→Int)∧ x.x logoP7



80/110




2


The identity function λα→α x.x has both these types: (Int→Int) ∧ (Bool→Bool) So it has their intersection. We can feed the identity to a function which expects argument of that type. But how do we relabel it? Intuitively: apply {Int/α} and {Bool/α} to the interface and replace it by the intersection of the two instances: ∧(Bool→Bool) λ(Int→Int)∧ x.x V We applied a set of type substitutions: t[σi ]i∈I = i∈I tσi

(λα→α x.x)[{Int/α}, {Bool/α}]


;


logoP7

80/110


4. Relabeling the body is not always straightforward:

logoP7



81/110




2


logoP7



81/110




2


logoP7



81/110




2


The identity function λα→α x.x has both these types: (Int→Int) ∧ (Bool→Bool)

logoP7



81/110




2


The identity function λα→α x.x has both these types: (Int→Int) ∧ (Bool→Bool) So it has their intersection.

logoP7



81/110




2


The identity function λα→α x.x has both these types: (Int→Int) ∧ (Bool→Bool) So it has their intersection. We can feed the identity to a function which expects argument of that type. But how do we relabel it?

logoP7



81/110




2


The identity function λα→α x.x has both these types: (Int→Int) ∧ (Bool→Bool) So it has their intersection. We can feed the identity to a function which expects argument of that type. But how do we relabel it? Intuitively: apply {Int/α} and {Bool/α} to the interface and replace it by the intersection of the two instances:

logoP7



81/110




2


The identity function λα→α x.x has both these types: (Int→Int) ∧ (Bool→Bool) So it has their intersection. We can feed the identity to a function which expects argument of that type. But how do we relabel it? Intuitively: apply {Int/α} and {Bool/α} to the interface and replace it by the intersection of the two instances: (λα→α x.x)[{Int/α}, {Bool/α}]

;

∧(Bool→Bool) λ(Int→Int)∧ x.x logoP7



81/110




2


The identity function λα→α x.x has both these types: (Int→Int) ∧ (Bool→Bool) So it has their intersection. We can feed the identity to a function which expects argument of that type. But how do we relabel it? Intuitively: apply {Int/α} and {Bool/α} to the interface and replace it by the intersection of the two instances: ∧(Bool→Bool) λ(Int→Int)∧ x.x V We applied a set of type substitutions: t[σi ]i∈I = i∈I tσi

(λα→α x.x)[{Int/α}, {Bool/α}]


;


logoP7

81/110




2


The identity function λα→α x.x has both these types: (Int→Int) ∧ (Bool→Bool) So it has their intersection. We can feed the the identity to a function which expects argument of that type. But how do we relabel it? Intuitively: apply {Int/α} and {Bool/α} to the interface and replace it by the intersection of the two instances: λ(Int→Int)∧(Bool→Bool) x.x V We applied a set of type substitutions: t[σi ]i∈I = i∈I tσi . (λα→α x.x)[{Int/α}, {Bool/α}]


;


logoP7

82/110




2


Consider again the daffy identity (λα→α x.(λα→α y .x)x). It also has type (Int→Int) ∧ (Bool→Bool)

logoP7



82/110




2


Consider again the daffy identity (λα→α x.(λα→α y .x)x). It also has type (Int→Int) ∧ (Bool→Bool) Applying the set of substitutions [{Int/α}, {Bool/α}] both to the interface and the body yields an ill-typed term: ∧(Bool→Bool) ∧(Bool→Bool) (λ(Int→Int)∧ x.(λ(Int→Int)∧ y .x)x)

logoP7



82/110




2


Consider again the daffy identity (λα→α x.(λα→α y .x)x). It also has type (Int→Int) ∧ (Bool→Bool) Applying the set of substitutions [{Int/α}, {Bool/α}] both to the interface and the body yields an ill-typed term: ∧(Bool→Bool) ∧(Bool→Bool) (λ(Int→Int)∧ x.(λ(Int→Int)∧ y .x)x)

Let us see why it is not well typed logoP7



82/110


In order to type ∧(Bool→Bool) ∧(Bool→Bool) (λ(Int→Int)∧ x.(λ(Int→Int)∧ y .x)x)

we must check that it has both types of the interface:

logoP7



83/110



we must check that it has both types of the interface: 1 2

∧(Bool→Bool) x : Int ` (λ(Int→Int)∧ y .x)x : Int

∧(Bool→Bool) x : Bool ` (λ(Int→Int)∧ y .x)x : Bool

logoP7



83/110






∧(Bool→Bool) Both fail because λ(Int→Int)∧ y .x is not well typed

logoP7



83/110







logoP7



83/110







Key idea The relabeling of the body must change according to the type of the parameter

logoP7



83/110







Key idea The relabeling of the body must change according to the type of the parameter In our example with (λα→α x.(λα→α y .x)x) and [{Int/α}, {Bool/α}]: logoP7



83/110







Key idea The relabeling of the body must change according to the type of the parameter In our example with (λα→α x.(λα→α y .x)x) and [{Int/α}, {Bool/α}]: logoP7



83/110







Key idea The relabeling of the body must change according to the type of the parameter In our example with (λα→α x.(λα→α y .x)x) and [{Int/α}, {Bool/α}]:

(λα→α y .x) must be relabeled as (λInt→Int y .x) when x : Int; (λα→α y .x) must be relabeled as (λBool→Bool y .x) when x : Bool logoP7



83/110


A new technique Observation This “dependent relabeling” is the stumbling block for the definition of an explicitly-typed λ-calculus with intersection types.

logoP7



84/110


A new technique Observation This “dependent relabeling” is the stumbling block for the definition of an explicitly-typed λ-calculus with intersection types. A new technique: “lazy” relabeling of bodies. Decorate λ-abstractions by sets of type-substitutions:

logoP7



84/110


A new technique Observation This “dependent relabeling” is the stumbling block for the definition of an explicitly-typed λ-calculus with intersection types. A new technique: “lazy” relabeling of bodies. Decorate λ-abstractions by sets of type-substitutions: To pass the daffy identity to a function that expects arguments of type (Int→Int) ∧ (Bool→Bool) first “lazily” relabel it as follows: α→α α→α (λ[{ y .x)x) Int/ },{Bool/ }] x.(λ α α

logoP7



84/110



The decoration indicates that the function must be relabeled

logoP7



84/110



The decoration indicates that the function must be relabeled The relabeling will be actually propagated to the body of the function at the moment of the reduction (lazy relabeling) logoP7



84/110



The decoration indicates that the function must be relabeled The relabeling will be actually propagated to the body of the function at the moment of the reduction (lazy relabeling) The new decoration is statically used by the type system to ensure soundness. Part 4: Polymorphic Language


logoP7

84/110


Details follow, but remember we want to program in this language e ::= x | ee | λ∧i∈I si →ti x.e | e∈t ? e : e No decorations: We do not want to oblige the programmer to write any explicit type substitution.

logoP7



85/110


Details follow, but remember we want to program in this language e ::= x | ee | λ∧i∈I si →ti x.e | e∈t ? e : e No decorations: We do not want to oblige the programmer to write any explicit type substitution. The technical development will proceed as follows: 1 Define a calculus with explicit type-substitutions and decorated λ-abstractions. 2 Define an inference system that deduces where to insert explicit type-substitutions in a term of the language above 3 Define a compilation and execution technique thanks to which type substitutions are computed only when strictly necessary (in general, as efficient as a monomorphic execution).

logoP7



85/110


Details follow, but remember we want to program in this language e ::= x | ee | λ∧i∈I si →ti x.e | e∈t ? e : e No decorations: We do not want to oblige the programmer to write any explicit type substitution. The technical development will proceed as follows: 1 Define a calculus with explicit type-substitutions and decorated λ-abstractions. 2 Define an inference system that deduces where to insert explicit type-substitutions in a term of the language above 3 Define a compilation and execution technique thanks to which type substitutions are computed only when strictly necessary (in general, as efficient as a monomorphic execution). Before proceeding we can already check our first yardstick: ∧(α\ \Int→α\ \Int) even = λ(Int→Bool)∧ x . x∈Int ? (x mod 2) = 0 : x

map = µm(α→β)→[α]→[β] f . λ[α]→[β] ` . `∈nil ? nil : (f (π1 `),mf (π2 `)) Part 4: Polymorphic Language


logoP7

85/110


A calculus with explicit type-substitutions

logoP7



86/110


A calculus with explicit type-substitutions Explicitly pinpoint where sets of type substitutions are applied: ∧

s →ti

i e ::= x | ee | λ[σi∈I j ]j∈J

x.e | e∈t ? e : e | e[σi ]i∈I

logoP7



87/110



s →ti


x.e | e∈t ? e : e | e[σi ]i∈I

logoP7



87/110



s →ti


x.e | e∈t ? e : e | e[σi ]i∈I

Some examples: (λα→α x.x)42 (λα→α x.x)[{Int/α}]42

logoP7



87/110



s →ti


x.e | e∈t ? e : e | e[σi ]i∈I

Some examples: (λα→α x.x)42 (λα→α x.x)[{Int/α}]42 (λα→α [{Int/

α}]

x.x)42

logoP7



87/110



s →ti


x.e | e∈t ? e : e | e[σi ]i∈I


α}]

x.x)42

(λα→α x.x)[{Bool/α}]42

logoP7



87/110



s →ti


x.e | e∈t ? e : e | e[σi ]i∈I


α}]

x.x)42

(λα→α x.x)[{Bool/α}]42 (λ(Int→Int)→Int y .y 3)(λα→α x.x) (λ(Int→Int)→Int y .y 3)((λα→α x.x)[{Int/α}]) Part 4: Polymorphic Language


logoP7

87/110



s →ti


x.e | e∈t ? e : e | e[σi ]i∈I


α}]

x.x)42

(λα→α x.x)[{Bool/α}]42 (λ(Int→Int)→Int y .y 3)(λα→α x.x) (λ(Int→Int)→Int y .y 3)((λα→α x.x)[{Int/α}])

logoP7

∧(Bool→Bool))→t (λ((Int→Int)∧ y .e)((λα→α x.x)[{Int/α}, {Bool/α}]) Part 4: Polymorphic Language


87/110


Reduction semantics ∧

s →ti


x.e | e∈t ? e : e | e[σi ]i∈I

logoP7



88/110



s →ti


x.e | e∈t ? e : e | e[σi ]i∈I

Relabeling operation e@[σj ]j∈J : pushes the type substitutions into the decorations of the λ’s inside e

logoP7



88/110



s →ti


x.e | e∈t ? e : e | e[σi ]i∈I

Relabeling operation e@[σj ]j∈J : [Pushes σ’s down into λ’s] def x@[σj ]j∈J = x def ∧ ti →si ∧i∈I ti →si x.e (λ[σk ]k∈K x.e)@[σj ]j∈J = λ[σi∈I k ]k∈K ◦[σj ]j∈J (e1 e2 )@[σj ]j∈J (e∈t ? e1 : e2 )@[σj ]j∈J (e[σk ]k∈K )@[σj ]j∈J

def

= = def =

def

(e1 @[σj ]j∈J )(e2 @[σj ]j∈J ) e@[σj ]j∈J ∈t ? e1 @[σj ]j∈J : e2 @[σj ]j∈J e@([σk ]k∈K ◦ [σj ]j∈J )

logoP7



88/110



s →ti


x.e | e∈t ? e : e | e[σi ]i∈I


def

= = def =

def


logoP7



88/110



s →ti


x.e | e∈t ? e : e | e[σi ]i∈I

Relabeling operation e@[σj ]j∈J : [Pushes σ’s down into λ’s] def x@[σj ]j∈J = x def ∧ ti →si ∧i∈I ti →si (λ[σk ]k∈K x.e)@[σj ]j∈J = λ[σi∈I x.e k ]k∈K ◦[σj ]j∈J k k∈K

k k∈K

(e1 e2 )@[σj ]j∈J (e∈t ? e1 : e2 )@[σj ]j∈J (e[σk ]k∈K )@[σj ]j∈J

def

= def = def =


logoP7



88/110



s →ti


x.e | e∈t ? e : e | e[σi ]i∈I


def

= = def =

def


logoP7



88/110



s →ti


x.e | e∈t ? e : e | e[σi ]i∈I


def

= = def =

def


Notions of reduction: e[σj ]j∈J ; e@[σj ]j∈J ∧

t →si

i (λ[σi∈I j ]j∈J

x.e)v

v ∈t ? e1 : e2 Part 4: Polymorphic Language

; (e@[σj ]j∈P ){v/x } e1 if ` v : t ; e otherwise

P = {j∈J | ∃i∈I , ` v : ti σj } logoP7

2


88/110



s →ti


x.e | e∈t ? e : e | e[σi ]i∈I


def

= = def =

def



t →si


x.e)v




2


88/110



s →ti


x.e | e∈t ? e : e | e[σi ]i∈I


def

= = def =

def



t →si


x.e)v




2


88/110


Example

(λ(Int→Int)∧(Bool→Bool) z.(λα→α x.(λα→α y .x)x)z)42

logoP7



89/110


Example

(λ(Int→Int)∧(Bool→Bool) z.(λα→α x.(λα→α y .x)x)z)42

logoP7



89/110


Example

(λ(Int→Int)∧(Bool→Bool) z.(λα→α x.(λα→α y .x)x)[{Int/α}, {Bool/α}]z)42

logoP7



89/110


Example

(λ(Int→Int)∧(Bool→Bool) z.(λα→α x.(λα→α y .x)x)[{Int/α}, {Bool/α}]z)42

logoP7



89/110


Example

(λ(Int→Int)∧(Bool→Bool) z.(λα→α x.(λα→α y .x)x)[{Int/α}, {Bool/α}]z)42 ;

(λα→α x.(λα→α y .x)x)[{Int/α}, {Bool/α}]42

logoP7



89/110


Example



; (λα→α [{Int/

α},{Bool/α}]

x.(λα→α y .x)x)42

logoP7



89/110


Example



; (λα→α [{Int/

α},{Bool/α}]


; (λInt→Int y .42)42

logoP7



89/110


Example

(λ(Int→Int)∧(Bool→Bool) z.(λα→α x.(λα→α y .x)x)[{Int/α}, {Bool/α}]z)42 ; ❀


; (λα→α ❀ [{Int/

α},{Bool/α}]


; (λInt→Int y .42)42 ❀

≡ (((λα→α y .x)x)@[{Int/α}]){42/x }

logoP7



89/110


Example



; (λα→α [{Int/

α},{Bool/α}]



≡ (((λα→α y .x)x)@[{Int/α}]){42/x }

logoP7



89/110


Example



; (λα→α [{Int/

α},{Bool/α}]



≡ (((λα→α y .x)x)@[{Int/α}]){42/x }

logoP7



89/110


Example



; (λα→α [{Int/

α},{Bool/α}]



≡ (((λα→α y .x)x)@[{Int/α}]){42/x }

; 42

logoP7



89/110


Type system (inst)

(subsumption)

Γ ` e : t1

t1 ≤t2

Γ ` e : t2

Γè:t

Γ ` e[σj ]j∈J

σj ] Γ ^ : tσj j∈J

(appl)

Γ ` e1 : t1 → t2

Γ ` e2 : t1

Γ ` e1 e2 : t2

(abstr )

Γ`

Γ, x : ti σj ` e@[σj ] : si σj i ∈I ^ ∧i∈I ti →si j ∈J λ[σj ]j∈J x.e : ti σj → si σj i∈I ,j∈J logoP7

[plus the rules for type-case and variables] Part 4: Polymorphic Language


90/110


Type system (inst)

(subsumption)

Γ ` e : t1

t1 ≤t2

Γ ` e : t2

Γè:t

Γ ` e[σj ]j∈J


(appl)

Γ ` e1 : t1 → t2

Γ ` e2 : t1

Γ ` e1 e2 : t2

(abstr )

Γ`




90/110


Type system (inst)

(subsumption)

Γ ` e : t1

t1 ≤t2

Γ ` e : t2

Γè:t

Γ ` e[σj ]j∈J


(appl)

Γ ` e1 : t1 → t2

Γ ` e2 : t1

Γ ` e1 e2 : t2

(abstr )

Γ`




90/110


Type system (inst)

(subsumption)

Γ ` e : t1

t1 ≤t2

Γ ` e : t2

Γè:t

Γ ` e[σj ]j∈J


(appl)

Γ ` e1 : t1 → t2

Γ ` e2 : t1

Γ ` e1 e2 : t2

(abstr )

Γ`




90/110


Properties Theorem (Subject Reduction) For every term e and type t, if Γ ` e : t and e ; e 0 , then Γ ` e 0 : t. Theorem (Progress) Let e be a well-typed closed term. If e is not a value, then there exists a term e 0 such that e ; e 0 .

logoP7



91/110


Properties Theorem (Subject Reduction) For every term e and type t, if Γ ` e : t and e ; e 0 , then Γ ` e 0 : t. Theorem (Progress) Let e be a well-typed closed term. If e is not a value, then there exists a term e 0 such that e ; e 0 . Theorem Let `BCD be Barendregt, Coppo, and Dezani, typing, and dee the type erasure of e. If `BCD a : t, then ∃e s.t. ` e : t and dee = a.

logoP7



91/110


Properties Theorem (Subject Reduction) For every term e and type t, if Γ ` e : t and e ; e 0 , then Γ ` e 0 : t. Theorem (Progress) Let e be a well-typed closed term. If e is not a value, then there exists a term e 0 such that e ; e 0 . Theorem Let `BCD be Barendregt, Coppo, and Dezani, typing, and dee the type erasure of e. If `BCD a : t, then ∃e s.t. ` e : t and dee = a. Note that e

∧

s →ti

i ::= x | ee | λ[σi∈I j ]j∈J

x.e | e∈t ? e : e | e[σi ]i∈I logoP7



91/110



∧

s →ti

i ::= x | ee | λ[σi∈I j ]j∈J




91/110



∧

s →ti

i ::= x | ee | λ[σi∈I j ]j∈J




91/110



∧

s →ti

i ::= x | ee | λ[σi∈I j ]j∈J

x.e | e∈t ? e : e | e[σi ]i∈I

satisfies the above theorem and is closed by reduction. Part 4: Polymorphic Language


logoP7

91/110



∧

s →ti

i ::= x | ee | λ[σi∈I j ]j∈J

x.e | e∈t ? e : e | e[σi ]i∈I

satisfies the above theorem and is closed by reduction, too. Part 4: Polymorphic Language


logoP7

91/110



∧

s →ti

i ::= x | ee | λ[σi∈I j ]j∈J

x.e | e∈t ? e : e | e[σi ]i∈I

The first n terms (n = 3, 4, 5) form an explicitly-typed λ-calculus logoP7 with intersection types subsuming BCD. Part 4: Polymorphic Language


91/110


Properties The definitions we gave: ∧(α\ \Int→α\ \Int) even = λ(Int→Bool)∧ x . x∈Int ? (x mod 2) = 0 : x

map = µm(α→β)→[α]→[β] f . λ[α]→[β] ` . `∈nil ? nil : (f (π1 `),mf (π2 `)) are well typed.

logoP7



92/110


Properties The definitions we gave: ∧(α\ \Int→α\ \Int) even = λ(Int→Bool)∧ x . x∈Int ? (x mod 2) = 0 : x

map = µm(α→β)→[α]→[β] f . λ[α]→[β] ` . `∈nil ? nil : (f (π1 `),mf (π2 `)) are well typed. A yardstick for the language Can define both map and even Can check the types specified in the signature Can deduce the type of the partial application map even logoP7



92/110


Inference of explicit type-substitutions

logoP7



93/110


Two problems: 1

Local type-substitution inference: Given a term of e ::= x | ee | λ∧i∈I si →ti x.e | e∈t ? e : e a sound & complete algorithm that, whenever possible, inserts sets of type-substitutions that make it a well-typed term of ∧

e ::= x | ee | λ[ ]i∈I

si →ti

x.e | e∈t ? e : e | e[σj ]j∈J

logoP7



94/110


Two problems: 1


e ::= x | ee | λ[ ]i∈I

si →ti

x.e | e∈t ? e : e | e[σj ]j∈J

(and, yes, the type inferred for map even is as expected)

logoP7



94/110


Two problems: 1


e ::= x | ee | λ[ ]i∈I

si →ti

x.e | e∈t ? e : e | e[σj ]j∈J

(and, yes, the type inferred for map even is as expected) 2

Type recostruction: Given a term λx.e find, if possible, a set of type-substitutions [σj ]j∈J such that λα→β [σj ]j∈J x.e logoP7

is well typed Part 4: Polymorphic Language


94/110


Local Type-Substitution Inference Given a term of e ::= x | ee | λ∧i∈I si →ti x.e | e∈t ? e : e Infer whether it is possible to insert sets of type-substitutions in it to make it a well-typed term of ∧

e ::= x | ee | λ[ ]i∈I

si →ti

x.e | e∈t ? e : e | e[σj ]j∈J

logoP7



95/110



e ::= x | ee | λ[ ]i∈I

si →ti

x.e | e∈t ? e : e | e[σj ]j∈J

logoP7



95/110



e ::= x | ee | λ[ ]i∈I

si →ti

x.e | e∈t ? e : e | e[σj ]j∈J

The reason is purely practical: λα→α x.3 must return a static type error



logoP7

95/110



e ::= x | ee | λ[ ]i∈I

si →ti

x.e | e∈t ? e : e | e[σj ]j∈J

The reason is purely practical: λα→α x.3 must return a static type error If we infer decorations, then it can be typed: λα→α x.3 {Int/ }

logoP7

α



95/110


The rule for applications 1. In the type system:

[with explicit type-subst.]

(Appl)

Γ ` e1 : s → u

Γ ` e2 : s

Γ ` e1 e2 : u

[The type of the function is subsumed to an arrow and the type of the argument is subsumed to the domain of this arrow].

logoP7



96/110




(Appl)

Γ ` e1 : s → u

Γ ` e2 : s

Γ ` e1 e2 : u


2. Subsumption elimination:


(Appl-algorithm)

Γ À e 1 : t

Γ À e 2 : s

t≤0→1

Γ À e1 e2 : min{u | t ≤ s → u} s ≤ dom(t)

logoP7



96/110




(Appl)

Γ ` e1 : s → u

Γ ` e2 : s

Γ ` e1 e2 : u




(Appl-algorithm)

Γ À e 1 : t

Γ À e 2 : s

t≤0→1


logoP7



96/110




(Appl)

Γ ` e1 : s → u

Γ ` e2 : s

Γ ` e1 e2 : u




(Appl-algorithm)

Γ À e 1 : t

Γ À e 2 : s

t≤0→1


logoP7



96/110




(Appl)

Γ ` e1 : s → u

Γ ` e2 : s

Γ ` e1 e2 : u




(Appl-algorithm)

Γ À e 1 : t

Γ À e 2 : s

t≤0→1

Γ À e1 e2 : min{u | t ≤ s → u} s ≤ dom(t) 3. Inference of type substitutions

[w/o explicit type-subst.]

(Appl-inference)

∃[σi ]i∈I , [σj0 ]j∈J

Γ Ì e1 : t

Γ Ì e1 e2 : min{u | Part 4: Polymorphic Language

t[σj0 ]j∈J

Γ Ì e2 : s t[σj0 ]j∈J ≤ 0 → 1 logoP7 0 ≤ s[σi ]i∈I → u} s[σi ]i∈I ≤ dom(t[σj ]j∈J )


96/110




(Appl)

Γ ` e1 : s → u

Γ ` e2 : s

Γ ` e1 e2 : u




(Appl-algorithm)

Γ À e 1 : t

Γ À e 2 : s

t≤0→1

Γ À e1 e2 : min{u | t ≤ s → u} s ≤ dom(t) 3. Inference of type substitutions

[w/o explicit type-subst.]

(Appl-inference)

∃[σi ]i∈I , [σj0 ]j∈J

Γ Ì e1 : t

Γ Ì e1 e2 : min{u | Part 4: Polymorphic Language

t[σj0 ]j∈J

Γ Ì e2 : s t[σj0 ]j∈J ≤ 0 → 1 logoP7 0 ≤ s[σi ]i∈I → u} s[σi ]i∈I ≤ dom(t[σj ]j∈J )


96/110


Tallying problem The problem of inferring the type of an application is thus to find for s and t given, [σi ]i∈I , [σj0 ]j∈J such that: t[σj0 ]j∈J ≤ 0 → 1 and

s[σi ]i∈I ≤ dom(t[σj0 ]j∈J )

This can be reduced to solving a suite of tallying problems Definition (Type tallying) Let C = {(s1 , t1 ), ..., (sn , tn )} a constraint set. A type-substitution σ is a solution for the tallying of C iff sσ ≤ tσ for all (s, t) ∈ C .

logoP7



97/110


Tallying problem The problem of inferring the type of an application is thus to find for s and t given, [σi ]i∈I , [σj0 ]j∈J such that: t[σj0 ]j∈J ≤ 0 → 1 and

s[σi ]i∈I ≤ dom(t[σj0 ]j∈J )

This can be reduced to solving a suite of tallying problems Definition (Type tallying) Let C = {(s1 , t1 ), ..., (sn , tn )} a constraint set. A type-substitution σ is a solution for the tallying of C iff sσ ≤ tσ for all (s, t) ∈ C . A sound and complete set of solutions for every tallying problem can be effectively found in three simple steps. logoP7



97/110


Step 1: Decompose constraints. Use the set-theoretic decomposition rules to transform C into a set of constraint sets whose constraints are of the form (α, t) or (t, α).

logoP7



98/110


Step 1: Decompose constraints. Use the set-theoretic decomposition rules to transform C into a set of constraint sets whose constraints are of the form (α, t) or (t, α). Step 2: Merge constraints on the same variable. if (α, t1 ) and (α, t2 ) are in C , then replace them by (α, t1∧ t2 ); if (s1 , α) and (s2 , α) are in C , then replace them by (s1∨ s2 , α); Possibly decompose the new constraints generated by transitivity.

logoP7



98/110


Step 1: Decompose constraints. Use the set-theoretic decomposition rules to transform C into a set of constraint sets whose constraints are of the form (α, t) or (t, α). Step 2: Merge constraints on the same variable. if (α, t1 ) and (α, t2 ) are in C , then replace them by (α, t1∧ t2 ); if (s1 , α) and (s2 , α) are in C , then replace them by (s1∨ s2 , α); Possibly decompose the new constraints generated by transitivity. Step 3: Transform into a set of equations. After Step 2 we have constraint-sets of the form {si ≤αi ≤ti | i ∈ [1..n]} where αi are pairwise distinct. 1 select s ≤ α ≤ t and replace it by α = (s∨ ∨β)∧ ∧t with β fresh. 2 in all other constraints in replace every α by (s∨ ∨β)∧ ∧t 3 repeat with another constraint

logoP7



98/110


Step 1: Decompose constraints. Use the set-theoretic decomposition rules to transform C into a set of constraint sets whose constraints are of the form (α, t) or (t, α). Step 2: Merge constraints on the same variable. if (α, t1 ) and (α, t2 ) are in C , then replace them by (α, t1∧ t2 ); if (s1 , α) and (s2 , α) are in C , then replace them by (s1∨ s2 , α); Possibly decompose the new constraints generated by transitivity. Step 3: Transform into a set of equations. After Step 2 we have constraint-sets of the form {si ≤αi ≤ti | i ∈ [1..n]} where αi are pairwise distinct. 1 select s ≤ α ≤ t and replace it by α = (s∨ ∨β)∧ ∧t with β fresh. 2 in all other constraints in replace every α by (s∨ ∨β)∧ ∧t 3 repeat with another constraint At the end we have a sets of equations {αi = ui | i ∈ [1..n]} that (with some care) are contractive. By Courcelle there exists a solution, ie, a substitution for α1 , ..., αn into (possibly recursive regular) types t1 , ..., tn (in which the fresh β’s are free variables). Part 4: Polymorphic Language


logoP7

98/110


The application problem Definition (Inference application problem) 0 Given s and ^ t types, find [σi ]i∈I and ^[σj ]j∈J such that: ^ tσi ≤ 0→1 and sσj ≤ dom( tσi ) i∈I

j∈J

i∈I

logoP7



99/110



1

j∈J

i∈I

Fix the cardinalities of I and J (at the beginning both 1);

logoP7



99/110



1 2

j∈J

i∈I

Fix the cardinalities of I and J (at the beginning both 1); Split each substitution σk (for k∈I ∪J) in two: σk = ρk ◦ σk0 where ρk is a renaming substitution mapping each variable of the V V V domain of σ k into a fresh variable: ( i∈I (tρi )σ 0i ≤ 0→1 and ( j∈J (sρj )σ 0j ≤ dom(( i∈I (tρi )σ 0i );

logoP7



99/110



1 2

j∈J

i∈I

Fix the cardinalities of I and J (at the beginning both 1); Split each substitution σk (for k∈I ∪J) in two: σk = ρk ◦ σk0 where ρk is a renaming substitution mapping each variable of the V V V domain of σ k into a fresh variable: ( i∈I (tρi )σ 0i ≤ 0→1 and ( j∈J (sρj )σ 0j ≤ dom(( i∈I (tρi )σ 0i );

logoP7



99/110



1 2

3

j∈J

i∈I

Fix the cardinalities of I and J (at the beginning both 1); Split each substitution σk (for k∈I ∪J) in two: σk = ρk ◦ σk0 where ρk is a renaming substitution mapping each variable of the V V V domain of σ k into a fresh variable: ( i∈I (tρi )σ 0i ≤ 0→1 and ( j∈J (sρj )σ 0j ≤ dom(( i∈I (tρi )σ 0i ); Solve the tallying problem for γ )} {(tV 1 , 0→1), (t1 , t2 →γ V γ with t1 = i∈I tρi , t2 = j∈J sρj , and fresh logoP7



99/110



1 2

3

j∈J

i∈I

Fix the cardinalities of I and J (at the beginning both 1); Split each substitution σk (for k∈I ∪J) in two: σk = ρk ◦ σk0 where ρk is a renaming substitution mapping each variable of the V V V domain of σ k into a fresh variable: ( i∈I (tρi )σ 0i ≤ 0→1 and ( j∈J (sρj )σ 0j ≤ dom(( i∈I (tρi )σ 0i ); Solve the tallying problem for γ )} {(tV 1 , 0→1), (t1 , t2 →γ V γ with t1 = i∈I tρi , t2 = j∈J sρj , and fresh if it fails at Step 1, then fail. logoP7 if it fails at Step 2, then change cardinalities (dove-tail)



99/110



1 2

3

j∈J

i∈I

Fix the cardinalities of I and J (at the beginning both 1); Split each substitution σk (for k∈I ∪J) in two: σk = ρk ◦ σk0 where ρk is a renaming substitution mapping each variable of the V V V domain of σ k into a fresh variable: ( i∈I (tρi )σ 0i ≤ 0→1 and ( j∈J (sρj )σ 0j ≤ dom(( i∈I (tρi )σ 0i ); Solve the tallying problem for γ )} {(tV 1 , 0→1), (t1 , t2 →γ V γ with t1 = i∈I tρi , t2 = j∈J sρj , and fresh if it fails at Step 1, then fail. logoP7 if it fails at Step 2, then change cardinalities (dove-tail) Every solution for γ is a solution for the application.



99/110


Example: map even Start with the following tallying problem: {(α1 →β 1 )→[α1 ]→[β 1 ] ≤ t→γγ } ∧(α\\Int→α\\Int) is the type of even where t = (Int→Bool)∧

logoP7



100/110


Example: map even Start with the following tallying problem: {(α1 →β 1 )→[α1 ]→[β 1 ] ≤ t→γγ } ∧(α\\Int→α\\Int) is the type of even where t = (Int→Bool)∧ At step 2 the algorithm generates 9 constraint-sets: one is unsatisfiable (t ≤ 0); four are implied by the others; remain {γγ ≥ [α1 ]→[β 1 ] , α1 ≤0} , {γγ ≥ [α1 ]→[β 1 ] , α1 ≤Int , Bool≤β 1 }, {γγ ≥ [α1 ]→[β 1 ] , α1 ≤α\\Int , α\\Int≤β 1 }, ∨Int , (α\\Int)∨ ∨Bool≤β 1 }; {γγ ≥ [α1 ]→[β 1 ] , α1 ≤α∨

logoP7



100/110


Example: map even Start with the following tallying problem: {(α1 →β 1 )→[α1 ]→[β 1 ] ≤ t→γγ } ∧(α\\Int→α\\Int) is the type of even where t = (Int→Bool)∧ At step 2 the algorithm generates 9 constraint-sets: one is unsatisfiable (t ≤ 0); four are implied by the others; remain {γγ ≥ [α1 ]→[β 1 ] , α1 ≤0} , {γγ ≥ [α1 ]→[β 1 ] , α1 ≤Int , Bool≤β 1 }, {γγ ≥ [α1 ]→[β 1 ] , α1 ≤α\\Int , α\\Int≤β 1 }, ∨Int , (α\\Int)∨ ∨Bool≤β 1 }; {γγ ≥ [α1 ]→[β 1 ] , α1 ≤α∨ γ Four solutions for : {γγ =[]→[]}, {γγ = [Int]→[Bool]}, {γγ = [α\\Int]→[α\\Int]}, ∨Int]→[(α\\Int)∨ ∨Bool]}. {γγ = [α∨



logoP7

100/110


Example: map even Start with the following tallying problem: {(α1 →β 1 )→[α1 ]→[β 1 ] ≤ t→γγ } ∧(α\\Int→α\\Int) is the type of even where t = (Int→Bool)∧ At step 2 the algorithm generates 9 constraint-sets: one is unsatisfiable (t ≤ 0); four are implied by the others; remain {γγ ≥ [α1 ]→[β 1 ] , α1 ≤0} , {γγ ≥ [α1 ]→[β 1 ] , α1 ≤Int , Bool≤β 1 }, {γγ ≥ [α1 ]→[β 1 ] , α1 ≤α\\Int , α\\Int≤β 1 }, ∨Int , (α\\Int)∨ ∨Bool≤β 1 }; {γγ ≥ [α1 ]→[β 1 ] , α1 ≤α∨ γ Four solutions for : {γγ =[]→[]}, {γγ = [Int]→[Bool]}, {γγ = [α\\Int]→[α\\Int]}, ∨Int]→[(α\\Int)∨ ∨Bool]}. {γγ = [α∨ logoP7 The last two are minimal and we take their intersection: ∧([α∨ ∨Int]→[(α\\Int)∨ ∨Bool])} {γγ = ([α\\Int]→[α\\Int])∧ Part 4: Polymorphic Language


100/110


On completeness and decidability The algorithm produces a set of solutions that is sound (it finds only correct solutions) and complete (any other solution can be derived from them).

logoP7



101/110


On completeness and decidability The algorithm produces a set of solutions that is sound (it finds only correct solutions) and complete (any other solution can be derived from them). Decidability: The algorithm is a semi-decision procedure. We conjecture decidability (N.B.: the problem is unrelated to typereconstruction for intersection types since we have recursive types).

logoP7



101/110


On completeness and decidability The algorithm produces a set of solutions that is sound (it finds only correct solutions) and complete (any other solution can be derived from them). Decidability: The algorithm is a semi-decision procedure. We conjecture decidability (N.B.: the problem is unrelated to typereconstruction for intersection types since we have recursive types). Completeness: For every solution of the inference problem, our algorithm finds an equivalent or more general solution. However, this solution is not necessary the first solution found. In a dully execution of the algorithm on map even the good solution is the second one. logoP7



101/110


On completeness and decidability The algorithm produces a set of solutions that is sound (it finds only correct solutions) and complete (any other solution can be derived from them). Decidability: The algorithm is a semi-decision procedure. We conjecture decidability (N.B.: the problem is unrelated to typereconstruction for intersection types since we have recursive types). Completeness: For every solution of the inference problem, our algorithm finds an equivalent or more general solution. However, this solution is not necessary the first solution found. In a dully execution of the algorithm on map even the good solution is the second one. Principality: This raises the problem of the existence of principal types: may an infinite sequence of increasingly general solutions exist? Part 4: Polymorphic Language


logoP7

101/110


Type reconstruction Solve sets of contraint-sets by the tallying algorithm: Γ `R x : Γ(x) ; {∅}

Γ `R

Γ, x : α `R e : t ; S λx.e : α → β ; S u {{(t ≤ β)}}

Γ `R e1 : t1 ; S1 Γ `R e2 : t2 ; S2 Γ `R e1 e2 : α ; S1 u S2 u {{(t1 ≤ t2 → α)}}

+

rule for typecase

logoP7



102/110



Γ `R



+

rule for typecase

Sound. it’s a variant: fix interfaces and infer decorations α→β λ[?] x.e Not complete: reconstruction is undecidable

logoP7



102/110



Γ `R



+

rule for typecase

Sound. it’s a variant: fix interfaces and infer decorations α→β λ[?] x.e Not complete: reconstruction is undecidable It types more than ML λx.xx : µX .(α∧(X →β)) → β

(≤ α∧(α→β))→β)

for functions typable in ML it deduces a type at least as good: logoP7

map : ((α→β) → [α]→[β]) ∧ ((0→1) → []→[]) Part 4: Polymorphic Language


102/110


Type Reconstruction Algorithm Γ `R c : bc ; {∅}

(R-const)

Γ `R x : Γ(x) ; {∅}

(R-var)

Γ `R m1 : t1 ; S1 Γ `R m2 : t2 ; S2 (R-appl) Γ `R m1 m2 : α ; S1 u S2 u {{(t1 ≤ t2 → α)}} Γ `R

Γ, x : α `R m : t ; S (R-abstr) λx.m : α → β ; S u {{(t ≤ β)}}

(R-case)

Γ `R

S = (S0 u {{(t0 ≤ 0)}}) t (S0 u S1 u {{(t0 ≤ t), (t1 ≤ α)}}) t (S0 u S2 u {{(t0 ≤ ¬t), (t2 ≤ α)}}) t (S0 u S1 u S2 u {{(t1 ∨ t2 ≤ α)}}) m0 : t0 ;S0 Γ `R m1 : t1 ;S1 Γ `R m2 : t2 ;S2 Γ `R (m0 ∈t ? m1 : m2 ) : α ; S

logoP7

where α, αi and β in each rule are fresh type variables. Part 4: Polymorphic Language


103/110


Efficient evaluation

logoP7



104/110


Monomorphic language e ::= c | x | λt x.e | ee | e ∈ t ? e : e v ::= c | hλt x.e, Ei

logoP7



105/110


Monomorphic language e ::= c | x | λt x.e | ee | e ∈ t ? e : e v ::= c | hλt x.e, Ei (Closure)

(Apply)

E `m λt x.e ⇓ hλt x.e, Ei

E `m e1 ⇓ hλt x.e, E 0 i

E `m e2 ⇓ v0

E `m e1 e2 ⇓ v

E 0 , x 7→ v0 `m e ⇓ v

logoP7



105/110



(Apply)

E⊢ `m λt x.e ⇓ hλt x.e, Ei

E` ⊢m e1 ⇓ hλt x.e, E 0′ i

E` ⊢m e2 ⇓ v0 E` ⊢m e1 e2 ⇓ v

`m e ⇓ v E ′0 , x 7→ v0 ⊢

logoP7



105/110



(Apply)

E⊢ `m λt x.e ⇓ hλt x.e, Ei

E` ⊢m e1 ⇓ hλt x.e, E 0′ i

E` ⊢m e2 ⇓ v0 E` ⊢m e1 e2 ⇓ v

`m e ⇓ v E ′0 , x 7→ v0 ⊢

logoP7



105/110



(Apply)

E `m λt x.e ⇓ hλt x.e, Ei

E `m e1 ⇓ hλt x.e, E 0 i

E `m e2 ⇓ v0

E `m e1 e2 ⇓ v

(Typecase True) E `m e1 ⇓ v0 v0 ∈m t E `m e2 ⇓ v E ` m e1 ∈ t ? e2 : e3 ⇓ v

c ∈m t s hλ x.e, Ei ∈m t Part 4: Polymorphic Language

E 0 , x 7→ v0 `m e ⇓ v

(Typecase False) E `m e1 ⇓ v0 v0 6∈m t E `m e3 ⇓ v E `m e1 ∈ t ? e2 : e3 ⇓ v def

= {c} ≤ t = s≤t

def


logoP7

105/110


Polymorphic language: naive implementation e ::= c | x | λtσI x.e | ee | e ∈ t ? e : e | eσI

(σI short for [σi ]i∈I )

logoP7



106/110


Polymorphic language: naive implementation e ::= c | x | λtσI x.e | ee | e ∈ t ? e : e | eσI v ::= c | hλtσJ x.e, E, σI i


logoP7



106/110



(Closure)


σI ; E `p λtσJ x.e ⇓ hλtσJ x.e, E, σI i

logoP7



106/110



(Closure) (Closure)

σI ; E

⊢ `p λσt J x.e

⇓

hλσt J x.e, E, σI i

(Instance)


σI ◦ σJ ; E `p e ⇓ v σI ; E `p eσJ ⇓ v

logoP7



106/110



(Closure) (Closure)

σI ; E

⊢ `p λσt J x.e

⇓


(Instance)



logoP7



106/110



(Closure)

σI ; E

`p λtσJ x.e

⇓

hλtσJ x.e, E, σI i

(Instance)



logoP7



106/110



(Closure)

σI ; E

`p λtσJ x.e

⇓


(Instance)

(Apply)

σI ; E `p e1 ⇓ hλσ∧K`∈L s` →t`x.e, E 0 , σH i σI ; E `p e2 ⇓ v0 σI ; E `p e1 e2 ⇓ v



σP ; E 0 , x 7→ v0 `p e ⇓ v

where σJ = σH ◦ σK and P = {j ∈ J | ∃` ∈ L : v0 ∈p s` σj }

logoP7



106/110



(Closure) (Closure) (Apply) (Apply)

σI ; E

⊢ `p λσt J x.e

⇓


(Instance) (Instance)

ℓ∈L `∈L sℓ ` →tℓ `x.e, E ′0 , σ ⊢p e1 ⇓ hλ∧ ⊢p e2 ⇓ v0 σI ; E ` H i σI ; E ` σK σI ; E ⊢ `p e1 e2 ⇓ v


σI ◦ σJ ; E ⊢ `p e ⇓ v σI ; E ⊢ `p eσJ ⇓ v

σP ; E ′0 , x 7→ v0 ⊢ `p e ⇓ v

where σJ = σH ◦ σK and P = {j ∈ J | ∃` ∃ℓ ∈ L : v0 ∈p s`ℓ σj }

logoP7



106/110



(Closure) (Closure) (Apply) (Apply)

σI ; E

⊢ `p λσt J x.e

⇓


(Instance) (Instance)

ℓ∈L `∈L sℓ ` →tℓ `x.e, E ′0 , σ ⊢p e1 ⇓ hλ∧ ⊢p e2 ⇓ v0 σI ; E ` H i σI ; E ` σK σI ; E ⊢ `p e1 e2 ⇓ v


σI ◦ σJ ; E ⊢ `p e ⇓ v σI ; E ⊢ `p eσJ ⇓ v

σP ; E ′0 , x 7→ v0 ⊢ `p e ⇓ v

where σJ = σH ◦ σK and P = {j ∈ J | ∃` ∃ℓ ∈ L : v0 ∈p s`ℓ σj }

logoP7



106/110



(Closure)

σI ; E

`p λtσJ x.e

⇓


(Instance)

(Apply)




σP ; E 0 , x 7→ v0 `p e ⇓ v


logoP7



106/110



(Closure)

σI ; E

`p λtσJ x.e

⇓


(Instance)

(Apply)




σP ; E 0 , x 7→ v0 `p e ⇓ v


Problem: At every application compute σP : logoP7



106/110



(Closure)

σI ; E

`p λtσJ x.e

⇓


(Instance)

(Apply)




σP ; E 0 , x 7→ v0 `p e ⇓ v


Problem: At every application compute σP : 1

compose of two sets of type-substitution



logoP7

106/110



(Closure)

σI ; E

`p λtσJ x.e

⇓


(Instance)

(Apply)




σP ; E 0 , x 7→ v0 `p e ⇓ v




2

select the substitutions compatible with the argument v0



logoP7

106/110



(Closure)

σI ; E

`p λtσJ x.e

⇓


(Instance)

(Apply)




σP ; E 0 , x 7→ v0 `p e ⇓ v




2

select the substitutions compatible with the argument v0



logoP7

106/110



(Closure)

σI ; E

`p λtσJ x.e

⇓


(Instance)

(Apply)




σP ; E 0 , x 7→ v0 `p e ⇓ v


Solution: Compute compositions and selections lazily. logoP7



106/110


Intermediate language as compilation target e v Σ

::= c | x | λtΣ x.e | ee | e ∈ t ? e : e ::= c | hλtΣ x.e, Ei ::= σI | comp(Σ, Σ0 ) | sel(x, t, Σ) symbolic substitutions (Closure)

(Apply)

E ` λtΣ x.e ⇓ hλtΣ x.e, Ei

E ` e1 ⇓ hλtΣ x.e, E 0 i

E ` e2 ⇓ v0

E ` e1 e2 ⇓ v

(Typecase True) E ` e1 ⇓ v0 v0 ∈ t E ` e2 ⇓ v E ` e1 ∈ t ? e2 : e3 ⇓ v

c ∈t s hλΣ x.e, Ei ∈ t Part 4: Polymorphic Language

E 0 , x 7→ v0 ` e ⇓ v

(Typecase False) E ` e1 ⇓ v0 v0 6∈ t E ` e3 ⇓ v E ` e1 ∈ t ? e2 : e3 ⇓ v def

= {c} ≤ t = s≤t

logoP7

def


107/110




(Apply)



E ` e2 ⇓ v0

E ` e1 e2 ⇓ v



E 0 , x 7→ v0 ` e ⇓ v


= {c} ≤ t = s≤t

logoP7

def


107/110




(Apply)



E ` e2 ⇓ v0

E ` e1 e2 ⇓ v



E 0 , x 7→ v0 ` e ⇓ v


= {c} ≤ t = s≤t

logoP7

def


107/110




(Apply)



E ` e2 ⇓ v0

E ` e1 e2 ⇓ v



E 0 , x 7→ v0 ` e ⇓ v


= {c} ≤ t = s≤t

logoP7

def


107/110




(Apply)



E ` e2 ⇓ v0

E ` e1 e2 ⇓ v



E 0 , x 7→ v0 ` e ⇓ v


= {c} ≤ t = s≤t

logoP7

def


107/110




(Apply)



E ` e2 ⇓ v0

E ` e1 e2 ⇓ v



E 0 , x 7→ v0 ` e ⇓ v


= {c} ≤ t = s(eval(E, Σ)) ≤ t

logoP7

def


107/110




(Apply)



E ` e2 ⇓ v0

E ` e1 e2 ⇓ v



E 0 , x 7→ v0 ` e ⇓ v


= {c} ≤ t = s(eval(E, Σ)) ≤ t

logoP7

def


107/110


Compilation 1

Compile into the intermediate language JxKΣ JλtσI x.eKΣ Je1 e2 KΣ JeσI KΣ Je1 ∈ t ? e2 : e3 KΣ

= x = λtcomp(Σ,σI ) x.JeKsel(x,t,comp(Σ,σI )) = Je1 KΣ Je2 KΣ = JeKcomp(Σ,σI ) = Je1 KΣ ∈ t ? Je2 KΣ : Je3 KΣ

logoP7



108/110


Compilation 1


2


def

For hλsΣ x.e, Ei ∈ t = s(eval(E, Σ)) ≤ t we have s(eval(E, Σ)) 6= s only if λsΣ x.e results from the partial application of a polymorphic function (ie, in s there occur free variables bound in the context).

logoP7



108/110


Compilation 1


2


def

For hλsΣ x.e, Ei ∈ t = s(eval(E, Σ)) ≤ t we have s(eval(E, Σ)) 6= s only if λsΣ x.e results from the partial application of a polymorphic function (ie, in s there occur free variables bound in the context). Execution is slowed only when testing the type of the result of a partial application of a polymorphic function. logoP7



108/110


Compilation 1


2


def

For hλsΣ x.e, Ei ∈ t = s(eval(E, Σ)) ≤ t we have s(eval(E, Σ)) 6= s only if λsΣ x.e results from the partial application of a polymorphic function (ie, in s there occur free variables bound in the context). Execution is slowed only when testing the type of the result of a partial application of a polymorphic function.

3

This holds also with products (used to encode lists records and logoP7 XML), whose testing accounts for most of the execution time.



108/110


Conclusion

logoP7



109/110


Theory: All the theoretical machinery necessary to design and implement a programming language is there. The practical relevance of the open theoretical issues is negligible.

logoP7



110/110


Theory: All the theoretical machinery necessary to design and implement a programming language is there. The practical relevance of the open theoretical issues is negligible. Languages: The polymorphic extension of CDuce is being implemented. Future applications: polymorphic extensions of XQuery and embedding some of this type machinery in ML.

logoP7



110/110


Theory: All the theoretical machinery necessary to design and implement a programming language is there. The practical relevance of the open theoretical issues is negligible. Languages: The polymorphic extension of CDuce is being implemented. Future applications: polymorphic extensions of XQuery and embedding some of this type machinery in ML. Runtime: Relabeling cannot be avoided but it is materialized only in case of partial polymorphic applications that end up in type-cases, that is, just when it is needed.

logoP7



110/110


Theory: All the theoretical machinery necessary to design and implement a programming language is there. The practical relevance of the open theoretical issues is negligible. Languages: The polymorphic extension of CDuce is being implemented. Future applications: polymorphic extensions of XQuery and embedding some of this type machinery in ML. Runtime: Relabeling cannot be avoided but it is materialized only in case of partial polymorphic applications that end up in type-cases, that is, just when it is needed. Implementation: Subtyping of polymorphic types require minimal modifications to the implementation. Existing data structures (e.g., binary decision trees with lazy unions) and optimizations mostly transpose smoothly.

logoP7



110/110


Theory: All the theoretical machinery necessary to design and implement a programming language is there. The practical relevance of the open theoretical issues is negligible. Languages: The polymorphic extension of CDuce is being implemented. Future applications: polymorphic extensions of XQuery and embedding some of this type machinery in ML. Runtime: Relabeling cannot be avoided but it is materialized only in case of partial polymorphic applications that end up in type-cases, that is, just when it is needed. Implementation: Subtyping of polymorphic types require minimal modifications to the implementation. Existing data structures (e.g., binary decision trees with lazy unions) and optimizations mostly transpose smoothly. Type reconstruction: Full usage needs more research, expecially about the production of human readable types and helpful error logoP7 messages, but it is mature enough to use it to type local functions. Part 4: Polymorphic Language


110/110