Black, A. P. and Hutchinson, N. "Typechecking Polymorphism in Emerald". Tech. Rep. CRL 91/1 (Revised), DEC Cambridge Research Lab., Cambridge, MA, July 1991.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....DataBase The keyword signals indicates the exceptions that can be signaled by the method. The keyword yields is used instead of returns in the case of an iterator. Type hierarchy Theta allows subtyping. In Theta, a subtype S must have all the methods of its supertype T with compatible signatures [16, 2, 4], plus perhaps some additional methods. If S is a subtype of T, an object of type S can be supplied as an argument where an object of type T is expected. 2.2 Thor architecture The Thor system is divided into the following components: ffl A set of distributed storage servers that persistently ....

Andrew P. Black and Norman Hutchinson. Typechecking polymorphism in Emerald. Technical Report 91/1, Digital Equipment Corporation, Cambridge Research Laboratory, December 1990.

....must be type checked again in the context of the subclass. The paper claims that Theta is type safe but provides no supporting evidence. We expect that the results of this paper can be used to add flexibility to their type system, while providing a proof of its type safety. The Emerald language [BH91] seems to have been the first to explicitly identify the relation of matching as distinct from subtyping. While Emerald does not contain classes, it supports the use of bounded matching to restrict polymorphic functions. The theoretical work most similar to that described here is [ESTZ94] That ....

A. Black and N. Hutchinson. Typechecking polymorphism in Emerald. Technical Report CRL 91/1 (Revised), DEC Cambridge Research Lab, 1991.

....x = new (obase) Deposit Impl1; x = new (obase) Deposit Impl2; x put money(1000) By the object handler x , all members member functions described in Deposit can be accessed, whether the actual implementation is Deposit Impl1 or Deposit Impl2 . This allows a new style of polymorphism[6]. Such assignment statements are allowed only if Deposit Impl1 and Deposit Impl2 implement the interface Deposit . Here, obase represents an object for the objectbase(a database in an OODBMS) 7] 3 Implementation Details In this section, we present our implementation which translates LOD ....

A. P. Black and N. Hutchinson. \Typechecking Polymorphism in Emerald". Technical report, DEC and UCB, 1991.

....HRB 87, JLHB88, Jul88] Emerald is unusual in lacking both classes and implementation inheritance: Emerald objects are completely self sufficient. Emerald does include a separate subtyping hierarchy, however, and recent versions include a powerful mechanism for statically type checked polymorphism [BH90]. All Emerald data structures are objects, and the only way to manipulate or access an object is to send it a message. Thus, Emerald is just as pure as Trellis Owl. Unfortunately, Emerald sacrifices complete purity and elegance for the sake of efficiency in a manner similar to the no subtypes ....

Andrew P. Black and Norman C. Hutchinson. Typechecking Polymorphism in Emerald. Technical report TR 90-34, Department of Computer Science, University of Arizona, December, 1990.

....constant, true) and maps all procedure names to the abort program, whereas the top of the type lattice ( Type ) contains no objects and maps all procedure names to the magic program. Comparing this with existing object oriented languages, the bottom type is similar to the Any type of Emerald [BH91] all objects belong to it, but nothing useful can be deduced about their behaviour. The ANY class of Eiffel and the Object class of Smalltalk are similar, except that they define a few procedures (that apply to all objects) so are actually refinements of Type . The top type Type is similar ....

Andrew P. Black and Norman Hutchinson. Typechecking polymorphism in Emerald. Digital Equipment Corporation, Cambridge Research Laboratory, July 1991. Ref. on page 89.

....distinctions in behavior that would not otherwise be expressed by a purely syntactic interface. This ameliorates some of the drawbacks of implicit subtyping. Emerald is another classless object oriented language with a static type system [Black et al. 86, Hutchinson 87, Hutchinson et al. 87, Black Hutchinson 90] Emerald is not based on multiple dispatching and in fact does not include support for inheritance of implementation. Types in Emerald are arranged in a subtype lattice, however. Formerly known as Owl and Trellis Owl. 86 Rapide [Mitchell et al. 91] is an extension of Standard ML modules ....

Andrew P. Black and Norman C. Hutchinson. Typechecking Polymorphism in Emerald. Technical report TR 90-34, Department of Computer Science, University of Arizona, December, 1990.

....and property compatibility. The language constructs introduced in this paper allow free mixing of property classes and normal classes in contrast to the two level approach (separating interfaces and implementations) in the papers above. An approach with a very similar type system is described in [1]. The main difference is the extension of the notion of inheritance 40 Franz Weber and conformance by considering axiomatic specifications and specifications by pre and postconditions of classes. The strongly typed object oriented languages Modula 3, Trellis and Simula are statically type safe ....

Andrew P. Black and Norman Hutchinson, Typechecking Polymorphism in Emerald, Technical Report CRL 91/1, DEC Cambridge Research Lab, 1991.

....93, Bruce et al. 93, Bruce et al. 95] and in Strongtalk [Bracha Griswold 93] a strongly typed extension of Smalltalk 80. As mentioned earlier, bounded matching and F bounded quantification have equivalent expressivity, but bounded matching is an arguably simpler means of expressing it [Black Hutchinson 91, Bruce 93] One of the underlying premises in all of the languages which utilize matching to constrain polymorphism is that subtyping and inheritance are two different, and not quite compatible, relationships that can be defined over classes [Snyder 86, Canning et al. 89b, Cook et al. 90] ....

....(including the contravariant rule for function subtyping) these languages define a matching relationship that captures similarities in the structure of two recursive types. Two types are said to match if their structure is identical. Rather than formally defining the matching relationship (see [Black Hutchinson 91, Bruce 93] we will rely on the example below as illustration. class Comparable signature = other:MyType) bool; class Point int x, y; method = other:MyType) bool; In PolyToil and its related languages, the special type MyType is used to refer to the type of the class currently being ....

Andrew P. Black and Norman C. Hutchinson. Typechecking Polymorphism in Emerald. Technical Report TR 90-34, Department of Computer Science, University of Arizona, December 1991.

....As pointed out in [AC95] a somewhat better encoding for matching can be obtained through the use of higher order subtyping [PS95] A concept similar to match bounded polymorphism seems to have been invented independently by several language designers. The term matching was introduced in [BH91] for a definition that is very similar to that of F bounded quantification. This construct was used in the distributed 36 class BTreeNode(T # Top; v:T) var value = v: T; left = nil: MyType; right = nil: MyType methods function getValue( T begin return value end; procedure setValue(newValue: ....

A. Black and N. Hutchinson. Typechecking polymorphism in Emerald. Technical Report CRL 91/1 (Revised), DEC Cambridge Research Lab, 1991.

....inheritance [CHC90] When used as the type of an instance, we interpret the reference to the protocol to mean selecting the first (primary) interface from the fixpoint of the protocol. The fact that types are interpreted as both generators and interfaces, according to context, has been noted in [BH91]. 4.3.1 The Metaclass Hierarchy and its Typing In this section, we briefly review the notion of metaclasses in Smalltalk, and present our treatment of the typing of metaclasses. Before delving into the Smalltalk metaclass hierarchy, readers should be aware of two facts. First, this section can be ....

....type errors, and can provide useful information for optimization. The system relies on global analysis, however, and is not well suited to incremental development. 6.2 Inherited Types The notion of inherited types has appeared in various related forms in several object oriented languages. Emerald [BH91] incorporates a similar notion called type matching. Emerald does not support class inheritance however. POOL [Ame90] is the imperative language most similar to Strongtalk in its type system. The theoretical foundations for inherited types were first given in [CCH 89] and [CHC90] The ....

Andrew P. Black and Norman Hutchinson. Typechecking polymorphism in Emerald. Technical Report CRL91/1 (Revised), DEC Cambridge Research Lab, July 1991.

....of a type parameter can be a function of the type parameter itself. This enables parameterized types to be used to describe patterns of types that are not necessarily subtypes of one another. Versions of F bounded polymorphism have appeared in singledispatching languages such as Emerald [Black Hutchinson 90] Axiom (formerly Scratchpad II) Watt et al. 88, Jenks Sutor 92] Strongtalk [Bracha Griswold 93] and k bench [Santas 93] In a singly dispatched language with F bounded polymorphism, the comparable type could be defined as follows: class comparable[T] signature = y:T) method ....

....distinctions in behavior that would not otherwise be expressed by a purely syntactic interface. This ameliorates some of the drawbacks of implicit subtyping. Emerald is another classless object oriented language with a static type system [Black et al. 86, Hutchinson 87, Hutchinson et al. 87, Black Hutchinson 90] Emerald is not based on multiple dispatching and in fact does not include support for inheritance of implementation. Types in Emerald are arranged in a subtype lattice, however. Formerly known as Owl and Trellis Owl. 89 Rapide [Mitchell et al. 91] is an extension of Standard ML modules ....

Andrew P. Black and Norman C. Hutchinson. Typechecking Polymorphism in Emerald. Technical report TR 90-34, Department of Computer Science, University of Arizona, December, 1990.

....is private; with function (x,y: t) return BOOLEAN is ; with function = x,y: t) return BOOLEAN is ; procedure sort (A: in out array ( of t) is . This is similar to the sort procedure written with bounded matching. Object oriented languages containing similar constructs are Emerald [8] and Theta [38] Returning to our example with Point , if f(p: Point) is a function accepting an argument of type Point then it can often be rewritten in the form f(T #Point ; p:T) so that it accepts a type parameter matching Point and an object of that type. If this type checks, then it will be ....

....argument be an object of the current class, and it may allow for a larger (with respect to the : relation) type of the argument of this method; by the contravariant subtyping rule for functions this produces a smaller type for the method. The informal idea is thus to give methods smaller types [7, 8]. By subsumption, these types can always be lifted to true binary form, allowing objects of the same class to be passed as arguments to the method. Thus, specifying a smaller type of a method can only increase its usability. Ingalls solution in Section 4.3 in fact depends on the use of precise ....

Andrew P. Black and Norman Hutchinson. Typechecking polymorphism in Emerald. Technical Report CRL 91/1 (Revised), Digital Equipment Corporation, Cambridge Research Lab, Cambridge, Mass., July 1991.

....Emerald (Black et al. 1986) is an object oriented language designed for distributed systems which has types and subtypes, but no classes or inheritance. It includes type parameters and introduces a notion similar to F bounded quantification to check the applicability of operations to types. (Black and Hutchinson, 1991) includes a careful discussion of its type system, including proofs that the dynamic type of an object always conforms to its static type, thereby ensuring the absence of message not understood error messages. Hense, 1991; Hense, 1990) present both a language design and semantics for an ....

A. Black and N. Hutchinson. Typechecking polymorphism in Emerald. Technical Report CRL 91/1 (Revised), DEC Cambridge Research Lab, 1991.

....the current version of Sather is type safe, it is still not as expressive as it might be. Some other languages have added the notion of matching, or F bounded polymorphism, to their type relations. In Sather, parametric polymorphism is defined in terms of subtypes. However, the language Emerald[BH91], and several other research languages, BSvG, DGLM94] show that requiring type parameters to be subtypes is too restrictive. All that is necessary to prove safe bounded polymorphism is matching, which is basically the relationship that exists between a subclass and a superclass. An object A ....

Andrew P. Black and Norman Hutchinson. Typechecking polymorphism in Emerald. Technical report, Digital Equipment Corporation, Cambridge Research Lab, 1991.

....types. F bounded polymorphism [Canning et al. 89, Cook et al. 90] is a different kind of subtyping relation that can describe that two objects come from the same type. One way of describing Fbounded polymorphism, adapted from Black and Hutchinson s version of F bounded polymorphism in Emerald [Black Hutchinson 90] is that a type definition is treated as a type generator, a function from a type to a type. The result type of the generator is the type being defined, with the change that what would be self references in the type are replaced with references to the argument type of the generator. To convert ....

Andrew P. Black and Norman C. Hutchinson. Typechecking Polymorphism in Emerald. Technical report TR 90-34, Department of Computer Science, University of Arizona, December, 1990.

....is private; with function (x,y: t) return BOOLEAN is ; with function = x,y: t) return BOOLEAN is ; procedure sort (A: in out array ( of t) is . This is similar to the sort procedure written with bounded matching. Object orientedlanguages containing similar constructs are Emerald [10], School [50] and Theta [40] Returning to our example with Point, if f(p: Point) is a functionaccepting an argument of type Point then it can often be rewritten in the form f(T #Point; p:T) so that it accepts a type parameter matching Point and an object of that type. If this type checks, then ....

....argument be an object of the current class, and it may allow for a larger (with respect to the : relation) type of the argument of this method; by the contravariant subtyping rule for functions this produces a smaller type for the method. The informal idea is thus to give methods smaller types [9, 10]. By subsumption, these types can always be lifted to true binary form, allowing objects of the same class to be passed as arguments to the method. Thus, specifying a smaller type of a method can only increase its usability. Ingalls solution in Section 4.3 in fact depends on the use of precise ....

Andrew P. Black and Norman Hutchinson. Typechecking polymorphism in Emerald. Technical Report CRL 91/1 (Revised), Digital Equipment Corporation, Cambridge Research Lab, Cambridge, Mass., July 1991.

No context found.

Black, A. P. and Hutchinson, N. "Typechecking Polymorphism in Emerald". Tech. Rep. CRL 91/1 (Revised), DEC Cambridge Research Lab., Cambridge, MA, July 1991.

....the dynamic type of an object will always conform to the syntactic type of any expression that evaluates to it. In symbols, if E and T return the value and the syntactic type of their arguments, we have E [ typeof n ] c T [ n ] This invariant is guaranteed by the Emerald type checker [8]. This means that, in general, if an identifier n is bound to an object b, only a subset of b s operations will be available for invocation on the target n. It is tempting to use this mechanism to restrict the operations that certain clients may perform on a particular object. However, ....

Black, A. P. and Hutchinson, N. "Typechecking Polymorphism in Emerald". Tech. Rep. CRL 91/1 (Revised), DEC Cambridge Research Lab., Cambridge, MA, July 1991.

No context found.

Andrew P. Black and Norman C. Hutchinson. Typechecking Polymorphism in Emerald. Technical report TR 90-34, Department of Computer Science, University of Arizona, December, 1990.

No context found.

Andrew P. Black and Norman C. Hutchinson. Typechecking Polymorphism in Emerald. Technical report TR 90-34, Department of Computer Science, University of Arizona, December, 1990.

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