J.C.Mitchell, G.D.Plotkin: Abstract types have existential type, Proc. POPL 1985.  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... types we have described is fundamentally the same as in CLU [Liskov 77] and has strong relations with OBJ2 s [Futatsugi Goguen Jouannaud Meseguer 85] although we handle only free algebras, without equations) The idea that existential quantifiers accurately model abstract types comes from [Mitchell Plotkin 85] Virtually all algebraic programming is conducted in the manysorted case, which makes it naturally typed. Concurrent programming. There is a different flavor of concurrent programming that fits with each of the programming styles above; concurrency is, in a sense, orthogonal to style. The ....

J.C.Mitchell, G.D.Plotkin: Abstract types have existential type, Proc. POPL 1985.

....right projection of a dependent product: lft = lA. lB:AType. lc: x:A. B(x) let x,y = c in x : A. B: AType. c: x:A. B(x) A rht = lA. lB:AType. lc: x:A. B(x) let x,y = c in y : A. B: AType. c: x:A. B(x) B(lft(A) B) c) 6. 11 Data abstraction Following Mitchell and Plotkin [Mitchell 85] it is possible to treat abstract types as existential types, given operators for building and examining objects of existential types [Girard 71] We consider here a pack operator, which packages an object so that it has an existential type (and hides some type information which is usually ....

J.C.Mitchell, G.D.Plotkin: Abstract types have existential type, Proc. POPL 1985.

....programming languages (e.g. Pascal) which are usually variations on the type system of first order typed l calculus. This phase distinction remains when generalizing to second order typed l calculus, which can be used to model parametric polymorphism (e.g. in ML [Milner 84] and abstract types [Mitchell 85] In all these languages, phases can be distinguished syntactically: there are separate syntactic sorts of type expressions and value expressions. Phase distinction are however lost when moving to languages like Pebble [Burstall 84a] based on dependent types [Martin Lf 73] A dependent type is a ....

....Erase(b) Erase(b( KT A) Erase(b) Erase(b( TT a) Erase(b) Erase(a) Erase(rec T (x:A) a) rec(x) Erase(a) This concludes the analysis of our basic type system. In the next sections we study some extensions. Existential Types Existential types can be used to model abstract types [Mitchell 85] and modules [Burstall 84b, MacQueen 86] Unlike other presentations, our pair objects are heavily typed to make their existential types unambiguous (some of this type information would be omitted in practice) In pair(x:A=a) b:B, the left and right components of the pair are a and b ....

J.C.Mitchell, G.D.Plotkin: Abstract types have existential type, Proc. POPL 1985.

....take types as arguments. We have tuples, including both tuples of values, such as 3,4 and mixed tuples of types and values, such as Int, 0, succ . In the latter case the type components of a tuple can only be handled in a limited way, so that these tuples represent elements of abstract types [Mitchell Plotkin 85] We have sets a, b, c and set operations. Sets of records are relations, which admit generalized relational algebra operations [Buneman Ohori 87] A value b=ref(c) is a modifiable reference to a value c; it can be dereferenced by deref(b) and assigned by b : c . Page 9 Recursion is used to ....

....Similarly, All[X: K]B : All[X: K ]B if K : K (where : denotes a subkind relation, discussed later) and B :B under the assumption that X: K . The type of a pair a,b is the cartesian product AB, for a:A and b:B. The types of mixed tuples of types and values (abstract types) are discussed in [Mitchell Plotkin 85] Set types A 1 , A n , relation types, and relation algebra operators are discussed in detail in [Ohori 87] For set types, A :B if for each A i in A there is a B j in B with A i j . The type of an assignable object ref(a) is Ref(A) if a:A. The subtyping rule for Ref types ....

J.C.Mitchell, G.D.Plotkin: Abstract types have existential type, Proc. POPL 1985.

....A and a right component of type B, where B may depend on the value of the left component (since it may have free occurrences of x) In the nondependent case, when x does not occur in B, we have a simple cartesian product, written AB. In case that A=Type, we have existential type quantification [Mitchell Plotkin 85] written x. B, and which can model abstract types and interfaces. For example, Some(A:Type)A(AInt) is the type of a package providing a constant of type A and an operation of type AInt over a hidden representation type A. Combining Page 8 dependent function and dependent pair types, one can ....

....Abstract types We have used the term abstract type for types of the form P = Some(A:Type) B, because this models the concept of having an unknown type A which supports a set of operations of signature B. It should be pointed out that, unlike abstract types in second order lambda calculus [Mitchell Plotkin 85] this notion of type abstraction does not prevent impersonation. That is, given a particular implementation p = pair(A:Type = C) b:B of P, the representation type C is visible, hence one can build an object of type A without using the operations in b. This problems can be partially solved by ....

J.C.Mitchell, G.D.Plotkin: Abstract types have existential type, Proc. POPL 1985.

....programming languages (e.g. Pascal) which are usually variations on the type system of first order typed l calculus. This phase distinction remains when generalizing to second order typed l calculus, which can be used to model parametric polymorphism (e.g. in ML [Milner 84] and abstract types [Mitchell 85] In all these languages, phases can be distinguished syntactically: there are separate syntactic sorts of type expressions and value expressions. Phase distinction are however lost when moving to languages like Pebble [Burstall 84a] based on dependent types [Martin Lf 73] A dependent type is a ....

....Erase(b) Erase(b( KT A) Erase(b) Erase(b( TT a) Erase(b) Erase(a) Erase(rec T (x:A) a) rec(x) Erase(a) This concludes the analysis of our basic type system. In the next sections we study some extensions. Existential Types Existential types can be used to model abstract types [Mitchell 85] and modules [Burstall 84b, MacQueen 86] Unlike other presentations, our pair objects are heavily typed to make their existential types unambiguous (some of this type information would be omitted in practice) In pair(x:A=a) b:B, the left and right components of the pair are a and b ....

J.C.Mitchell, G.D.Plotkin: Abstract types have existential type, Proc. POPL 1985.

.... types we have described is fundamentally the same as in CLU [Liskov 77] and has strong relations with OBJ2 s [Futatsugi Goguen Jouannaud Meseguer 85] although we handle only free algebras, without equations) The idea that existential quantifiers accurately model abstract types comes from [Mitchell Plotkin 85] Virtually all algebraic programming is conducted in the manysorted case, which makes it naturally typed. Concurrent programming. There is a different flavor of concurrent programming that fits with each of the programming styles above; concurrency is, in a sense, orthogonal to style. The ....

J.C.Mitchell, G.D.Plotkin: Abstract types have existential type, Proc. POPL 1985.

.... over types (l(X: TYPE) and type application, and the function space operator ( along with l abstraction over values (l(x:X) and value application: let id : P(X: TYPE) XX) l(X: TYPE) l(x:X) x id(Int) 3) 3 : Int Abstract types are obtained by existential quantification over types (S) Mitchell Plotkin 85] As is well known, these existential quantifiers, with their associated primitives, can be defined in terms of P and . Similarly, cartesian product ( can be defined from . The following might be the type of a package providing an abstract type X, a constant of type X, and an operation from X ....

J.C.Mitchell, G.D.Plotkin: Abstract types have existential type, Proc. POPL 1985.

....and Hindley [Hindley 69] or general universal quantification (this is the Girard Reynolds type system [Girard 71] Reynolds 74] Up on the right we have type systems with type abstraction, characterized by existential quantification. Joining universal and existential quantifiers we obtain SOL s [Mitchell 85] type system, which can be used to explain basic module features. The remaining points at the top have to do with inclusion. We have shown that the bounded universal quantifiers are needed to model object oriented programming, and bounded existential quantifiers are needed to mix inheritance with ....

J.C.Mitchell, G.D.Plotkin: Abstract types have existential type, Proc. Popl 1985.

No context found.

J.C.Mitchell, G.D.Plotkin: Abstract types have existential type, Proc. POPL 1985.

No context found.

J.C.Mitchell, G.D.Plotkin: Abstract types have existential type, Proc. POPL 1985.

No context found.

J.C.Mitchell, G.D.Plotkin: Abstract types have existential type, Proc. POPL 1985.

No context found.

J.C.Mitchell, G.D.Plotkin: Abstract types have existential type, Proc. POPL 1985.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC