Results 1 
3 of
3
Detecting Common Elements of Types
 TRENDS IN FUNCTIONAL PROGRAMMING, VOLUME 2. INTELLECT
, 2000
"... We describe an algorithm approximating the following question: Given two types t 1 and t 2 , are there instances s(t 1 ) and s(t 2 ) denoting a common element ? By answering this question we solve a main problem towards a type checking algorithm for nondisjoint types that raises an error just for ..."
Abstract

Cited by 2 (2 self)
 Add to MetaCart
We describe an algorithm approximating the following question: Given two types t 1 and t 2 , are there instances s(t 1 ) and s(t 2 ) denoting a common element ? By answering this question we solve a main problem towards a type checking algorithm for nondisjoint types that raises an error just for function calls that cannot be executed successfully. For dynamically typed functional languages such a type checker can extend actual soft typing systems in order to reject provably illtyped programs.
Chapter 1 Detecting Common Elements of Types
"... two types t1 and t2, are there instances σ(t1) and σ(t2) denoting a common element? By answering this question we solve a main problem towards a type checking algorithm for nondisjoint types that raises an error just for function calls that cannot be executed successfully. For dynamically typed fun ..."
Abstract
 Add to MetaCart
(Show Context)
two types t1 and t2, are there instances σ(t1) and σ(t2) denoting a common element? By answering this question we solve a main problem towards a type checking algorithm for nondisjoint types that raises an error just for function calls that cannot be executed successfully. For dynamically typed functional languages such a type checker can extend actual soft typing systems in order to reject provably illtyped programs. 1.1
Chapter 1 Function Types in Complete Type Inference
"... Abstract: We study type checking that is complete in the sense that it accepts every program whose subexpressions can all be executed without raising a type error at runtime. In a complete type checker for every function call ( f a) of a function f with an argument expression a of type ta it is chec ..."
Abstract
 Add to MetaCart
(Show Context)
Abstract: We study type checking that is complete in the sense that it accepts every program whose subexpressions can all be executed without raising a type error at runtime. In a complete type checker for every function call ( f a) of a function f with an argument expression a of type ta it is checked whether f is applicable to one of the possible values of a,i.e.whether〈[ta]〉∩dom ( f) � = /0 holds where 〈[t] 〉 denotes the semantics of a type t. When approximating dom ( f) by a type tin it turns out that the usual function type constructor is not appropriate for complete type checking: for a function type t f = tin → tout of f the input type tin is usually not guaranteed to contain all values of dom ( f) and the test for common elements can erroneously fail. We therefore introduce an alternative notion of function types, called I/Orepresentation, where the input types cover a superset of the domain of the denoted functions. We show that this notion of function types fits into the framework of complete type checking much better than the usual function type constructor. Moreover, we argue that complete type checking overcomes the disadvantages of softtyping approaches by enabling the rejection