Tobias Nipkow and Christian Prehofer. Type checking type classes. In Proc. 20th ACM Symp. Principles of Programming Languages, pages 409--418, 1993.  Home/Search   Document Details and Download   Summary   Related Articles   Check

.... primitive rule causes many technical subtleties of the resulting structure of derivations, much unnecessary e#ort has been required for the original meta theory of overloaded definitions [Wenzel, 1994] Wenzel, 1997] Note that the additional concept of order sorted type classes of Isabelle Pure [Nipkow, 1993] [Nipkow and Prehofer, 1993] has been treated as an admissible extension of the basic inference system before [Wenzel, 1997] see also 7.2.4 the end user view of type classes and overloading. Generally speaking, our presentation of the pure framework has been made more conforming to common ....

.... causes many technical subtleties of the resulting structure of derivations, much unnecessary e#ort has been required for the original meta theory of overloaded definitions [Wenzel, 1994] Wenzel, 1997] Note that the additional concept of order sorted type classes of Isabelle Pure [Nipkow, 1993] [Nipkow and Prehofer, 1993] has been treated as an admissible extension of the basic inference system before [Wenzel, 1997] see also 7.2.4 the end user view of type classes and overloading. Generally speaking, our presentation of the pure framework has been made more conforming to common presentations of natural ....

[Article contains additional citation context not shown here]

T. Nipkow and C. Prehofer. Type checking type classes. In 20th ACM Symp. Principles of Programming Languages, 1993.

....type classes. A type class is an inductively defined set of types. A type class qualification (or class constraint) can be used to restrict a polymorphic type to the members of a particular class (or classes) A number of works have tried to explain type inference for Haskell from first principles [28, 29]. Subsequently, further extensions have been investigated. In his thesis [13] Jones has investigated qualified types. Qualified types can be instantiated to a range of interesting type systems, among them type classes, record types, and subtyping. This work has paved the way for more ....

T. Nipkow and C. Prehofer. Type checking type classes. In Proceedings of the 1993.

.... . instance Eq (a, b) Eq a Eq b where . Predicates can be combined by conjunction . In Haskell, type classes can form a hierarchy where new classes can inherit operations from existing superclasses. We do not consider superclasses here because they can be expanded to sets of classes [5, 39]. 3. PRELIMINARIES A ranked alphabet is a finite set of symbols with associated arities. Let further be a set of variables. The set TA(X ) is the set of terms over alphabet and variables . That is, it is the smallest set with X # TA(X ) and, whenever f # A with arity n N and ....

....narrowing as described in Sections 6.1 and 6.3. 8. RELATED WORK There have been many approaches to adding overloading to languages with a Hindley Milner style polymorphic type system, beginning with Kaes [33] and Wadler and Blott [49] and later picked up, refined, and implemented by many others [40, 5, 39, 3, 26, 42, 15, 27, 29, 43, 35, 31]. In particular, recent work is pushing hard the borders of complete and decidable type inference [45, 46] In the face of this plethora, we only consider the most closely related work here. The work of Jones [27] and its extension to constructor classes [26] provides a general framework for type ....

T. Nipkow and C. Prehofer. Type checking type classes. In Proceedings of the 1993.

....ML [5] uses uni cation for solving constraints in the type language and several extensions of this algorithm are based on extensions of the uni cation algorithms with some kind of constraint resolution mechanism. Some examples include record systems [15] and type inference dealing with overloading [20, 12, 14]. The same happens for object oriented languages where the previous systems are extended with the notion of subtyping [2, 6, 7] Subtyping is modeled by solving subtype constraints in the type inference process. In this context Odersky, Sulzmann and Wehr de ned the HM(X ) framework, 19] as a ....

Tobias Nipkow and Christian Prehofer. Type checking type classes. In Proc. 20th ACM Symp. Principles of Programming Languages. ACM Press, 1993.

....10 level of ordered type classes (or sorts) that qualify types. Thus the algebra of types becomes an order sorted structure that is amenable to well known techniques like order sorted unification [14] In particular, ml style type inference can be easily generalized to the order sorted system [9,10]. Order sorted Type Signatures consist of three basic components: a finite set C of type classes, a class inclusion relation #, and a set of type arities. The initial class structure (C, #) is canonically extended to a quasi ordered sort structure (S, #) such that sorts are finite sets of ....

T. Nipkow and C. Prehofer. Type checking type classes. In 20th ACM Symp. Principles of Programming Languages, 1993.

....in type expressions and leads to a particularly simple implementation. In addition, this permits further useful extensions such as the possibility of defining overlapping instances. Several researchers, including this author, have investigated the theory and formal properties of type classes [8, 30, 29, 36, 44, 45, 50, 53] and there has 27 also been some experience with practical implementations [14, 28, 46, 5] and applications [27, 38, 13] Since these topics are so well documented, we will concentrate here only on the special features in the implementation of Gofer. We will also assume that the reader is ....

Tobias Nipkow and Christian Prehofer. Type checking type classes. In Proceedings 20th Symposium on Principles of Programming Languages. ACM, January 1993.

....views. Like views, Haskell s type classes allow a distributed definition of functionality over data types. Qualification of type variables in a qualified type corresponds to F bounded qualification of views [CCH 89] A number of di#erent designs for type classes have been developed [HHPW94, NP93, Jon92, Jon93, Jon00] Our view proposal is most closely related to parametric type classes [CHO92] in that the bound of a type variable a may have additional parameters other than a itself. Type classes are usually studied in systems without subtyping. Where subtyping is added [Kae92] name ....

Tobias Nipkow and Christian Prehofer. Type checking type classes. In Proc. 20th ACM Symposium on Principles of Programming Languages, pages 409--418, 1993.

....10 level of ordered type classes (or sorts) that qualify types. Thus the algebra of types becomes an order sorted structure that is amenable to well known techniques like order sorted unification [14] In particular, ml style type inference can be easily generalized to the order sorted system [9, 10]. Order sorted Type Signatures consist of three basic components: a finite set C of type classes, a class inclusion relation , and a set of type arities. The initial class structure (C; is canonically extended to a quasi ordered sort structure (S; v) such that sorts are finite sets of classes: ....

T. Nipkow and C. Prehofer. Type checking type classes. In 20th ACM Symp. Principles of Programming Languages, 1993.

....the main difference between Gordon s HOL and Isabelle s HOLC is the availability of type classes in HOLC. The concept of type classes is not specific to the object logic HOLC; it is derived from Isabelle s meta logic. In the beginning type classes were introduced in Isabelle by Nipkow [Nip91, NP93] as a purely syntactic device. They admit a fine grained use of polymorphism for the description of object logics. Since type classes are available in the meta logic they can be used in object logics, too. However, this is only sensible if the semantics of the object logic gives meaning to the ....

....more verbose phrase v: ff: term ) ff ) bool. In the three axioms of the example above it is not necessary to mention any types since the type inference mechanism can deduce all of the needed information. The technique of type inference for type class polymorphism is addressed in full detail in [NP93] The theory Porder0 first is problematic for two reasons. First of all the theory constitutes an extension which is not safe in the sense of HOL. 2 We used three axioms to specify the notion of a partial order instead of using definitions which is prefered in HOL since definitions preserve ....

Tobias Nipkow and Christian Prehofer. Type checking type classes. In Proc. 20th ACM Symp. Principles of Programming Languages, pages 409-- 418, 1993.

....be to define the semantics directly on well formed derivations for implicitly typed terms avoiding the introduction of an explicitly typed language. However, since the type system of Spectrum is an instance of the type system of Isabelle, we preferred to use an explicit type system and refer to [16, 17] for results about principal typings. enough information. For the object variables, however, there are several binders and therefore we need an explicit variable context. Definition7 Sort Assertions. The set of sort assertions consists of tuples ( Gamma; e; where: is a sort ....

Tobias Nipkow and Christian Prehofer. Type checking type classes. In Proc. 20th ACM Symp. Principles of Programming Languages, pages 409--418, 1993.

....and Data Organization Am Fasanengarten 5, 76128 Karlsruhe, Germany fsulzmann,odersky,wehrg ira.uka.de 1 Introduction There are many type systems that extend the Hindley Milner [Mil78] system with constraints. Examples are found in record systems [Oho95, Rem89] overloading [Jon92, HHJW96, NP93, KC92, OWW95] and systems that support subtyping [CCH 89, BSvG95, AW93, EST95] Extensions of Hindley Milner with constraints are also increasingly popular in program analysis [DHM95, TJ92] Even though these type systems use different constraint domains, they are largely alike in their ....

....relation for type classes 6 Type Classes With the use of the proposed constraint type system it is simple to include type classes in a Hindley Milner type system. We compare two approaches to realize type classes. First we restate the inference mechanism proposed by Nipkow and Prehofer in [NP93] A look at this algorithm will lead to the observation that the style of this type system is that of a constraint type system. We then consider the approach of Jones [Jon92] This example will shed a light on the two constraint systems we are using, the general system D and the normalized C. Our ....

Tobias Nipkow and Christian Prehofer. Type checking type classes. POPL, pages 409--418, 1993.

....are used to build sort terms. Definition 1.2 The standard (predefined) sort signature 3 Order kinded would be more precise; see [GM87, Gog76] for order sorted algebras. In the sequel we will use order sorted and mean order sorted on the level of kinds. 4 See [SNGM89] for a definition. NP] use slightly different criteria. The standard sort signature: Omega standard = fcpo; mapg; ffBoolg cpo ; f g cpo cpo; cpo ; ftog cpo cpo; map ; f Theta n g cpo: cpo z n times ; cpo g ) contains two kinds and four sort constructors (actually, we have for each n a sort ....

....define the semantics directly on well formed derivations for implicitly typed terms avoiding the introduction of an explicitly typed language. However, since the type system of Spectrum is an instance of the type system of Isabelle, we preferred to use an explicit type system and refer to [Nip93, NP] for results about principal typings. context free syntax of pre terms via a BNF like grammar. In the second step we introduce a calculus for well formed terms that uses formation rules to express the context sensitive part of the syntax. Context Free Language (Pre Terms) term : ....

Tobias Nipkow and Christian Prehofer. Type checking type classes. In Proc. 20th ACM Symp. Principles of Programming Languages, pages 409--418.

.... into Haskell in order to provide a uniform framework for overloading [WB89] It must have been an idea whose time had come, as it was independently described by Kaes [Kae88] Since then type classes have attracted considerable attention, with many refinements and variants being described [NS91, NP93, HHPW94, Aug93, PJ93, Jon92b, CHO92, Jon93] They have also attracted some criticism [App93] In our view, one of the most serious criticisms of type classes is that a program cannot be assigned a meaning independent of its types. A consequence of this is that two of Institut fur ....

....rid of all syntactic declarations of predicates or type classes. We extend the scope of his work by a proof of type soundness and the relationship to record typing. Much of the later work on overloading is driven by the design and implementation of Haskell s type classes, e.g. Nipkow et al. NS91, NP93] on type reconstruction, Augustsson [Aug93] and Peterson and Jones [PJ93] on implementations, and Hall, Hammond, Peyton Jones and Wadler [HHPW94] on the formal definition of type classes in Haskell. We have already compared our system to that of Haskell. Other generalisations of Haskell type ....

Tobias Nipkow and Christian Prehofer. Type checking type classes. In Proc. 20th ACM Symposium on Principles of Programming Languages, pages 409--418, 1993.

....its most innovative feature, and has provoked much discussion. There has been closely related work by Rouaix [Rou90] and Comack and Wright [CW90] and work directly inspired by type classes includes Nipkow and Snelting [NS91] Volpano and Smith [VS91] Jones [Jon92a, Jon93] Nipkow and Prehofer [NP93] Odersky and Laufer [OdLa91] Laufer [Lau92, Lau93] and Chen, Hudak and Odersky [CHO92] The paper presents a source language (lambda calculus with implicit typing and with overloading) and a target language (polymorphic lambda calculus with explicit typing and without overloading) The ....

....adopted many of the same techniques they use for mastering complexity. This approach unites theory and practice. The industrial grade rules given here provide a useful complement to the more theoretical approaches of Wadler and Blott [WB89, Blo91] Nipkow and Snelting [NS91] Nipkow and Prehofer [NP93] and Jones [Jon92a, Jon93] A number of simplifying assumptions made in those papers are not made here. Unlike [WB89] it is not assumed that each class has exactly one operation. Unlike [NS91] it is not assumed that the intersection of every pair of classes must be separately declared. Unlike ....

T. Nipkow and C. Prehofer, Type Checking Type Classes. In ACM Symposium on Principles of Programming Languages, January 1993, pp. 409--418.

..... Each type that supports a group of overloaded functions is declared as an instance of the corresponding class. Algorithmic type inference of principal types in the style of Hindley and Milner is possible for ML like languages extended with type classes, such as Haskell (Chen et al. 1992, Nipkow and Prehofer, 1993). Existential types (Mitchell and Plotkin, 1988, Cardelli and Wegner, 1985) are a formalization of the concept of abstract data type, such as the package in Ada (United States Department of Defense, 1983) the cluster in CLU (Liskov and Guttag, 1986) and the module in Modula 2 (Wirth, 1985) By ....

....0.32) MakePoint(MakeColPoint (C(4.00, 6.00) Blue) MakePoint(C(3.00, 9.00) MakePoint(MakeColPoint (P(7.16, 0.89) Red) 4 The Formal Language Exell In this section, we formally describe the syntax of expressions and types in our language, Exell. Exell is an extension of Mini Haskell (Nipkow and Prehofer, 1993) with user defined algebraic data types. While Mini Haskell is not strictly a subset of the Haskell language, it captures the essential features of Haskell relating to type classes. The resulting language is a l calculus with let expressions, extended with class, instance, and data type ....

[Article contains additional citation context not shown here]

Nipkow, T. and Prehofer, C. 1993. Type checking type classes. In Proc. 20th ACM Symp. Principles of Programming Languages.

....example is the treatment of overloading proposed by Wadler and Blott [25] in which overloading is represented by introducing so called dictionary ab stractions and applications. This basic idea has been used in all current implementations of Haskell type classes [8] and has been widely studied [1, 9, 10, 12, 17, 18, 21, 23, 24]. This paper is motivated by the observation that both ideas can be dealt with in the same framework, allowing us to exploit the connections between the two systems so that results and ideas originally developed with one application in mind can also be applied to the other. More precisely, we show ....

T. Nipkow and C. Prehofer. Type checking type classes. In 20th Annual Symposium on Principles of Programming Languages, Charleston, South Carolina, January 1993.

....corresponds to a parameterized specification. In that case N is also an algebraic specification and the actual parameters are initial algebras. As expected, they must contain the necessary operations and satisfy the formal parameter axioms 9 . A restricted form of ADTs is given by type classes [90, 76, 45, 44]. In this case, all algebras from a type class must have a different representation type. This allows, for each context, the automatic inference of the right algebra. As a consequence no explicit open operation is necessary. Moreover, N does not need to be a specification. Since axioms cannot be ....

Tobias Nipkow and Christian Prehofer. Type checking type classes. In Proc. 20th ACM Symp. Principles of Programming Languages, pages 409--418, 1993.

....in computational resources and in some cases they can introduce inconsistencies. 8. Type Classes In this section, we are concerned with modeling subtyping without use of coercions. We introduce the concept of type classes, which has some similarities with the homonymous concept in Haskell (Nipkow and Prehofer, 1993, Wadler and Blott, 1991) The semantics and the formal definitions for type classes are provided in section 8.1. Type classes are distinct from categories in the sense that they are not part of the user defined types. The main difference with Haskell s type classes is that our type classes are ....

Nipkow, T., Prehofer, C. (1993). Type Checking Type Classes. Proc. of the 20th Sumposiumon Principles of Programming Languages. ACM Press.

....feature, and has provoked much discussion. There has been closely related work by Rouaix [ Rou90 ] and Comack and Wright [ CW90 ] and work directly inspired by type classes includes Nipkow and Snelting [ NS91 ] Volpano and Smith [ VS91 ] Jones [ Jon92a, Jon93 ] Nipkow and Prehofer [ NP93 ] Odersky and Laufer [ OdLa91 ] Laufer [ Lau92, Lau93 ] and Chen, Hudak and Odersky [ CHO92 ] The paper presents a source language (lambda calculus with implicit typing and with overloading) and a target language (polymorphic lambda calculus with explicit typing and without overloading) ....

....many of the same techniques they use for mastering complexity. This approach unites theory and practice. The industrial grade rules given here provide a useful complement to the more theoretical approaches of Wadler and Blott [ WB89, Blo91 ] Nipkow and Snelting [ NS91 ] Nipkow and Prehofer [ NP93 ] and Jones [ Jon92a, Jon93 ] A number of simplifying assumptions made in those papers are not made here. Unlike [ WB89 ] it is not assumed that each class has exactly one operation. Unlike [ NS91 ] it is not assumed that the intersection of every pair of classes must be separately ....

T. Nipkow and C. Prehofer, Type Checking Type Classes. In ACM Symposium on Principles of Programming Languages, January 1993, pp. 409--418.

....new overloaded functions . Each type that supports a group of overloaded functions is declared as an instance of the corresponding class. Algorithmic type inference of principal types in the style of Hindley and Milner is possible for ML like languages extended with type classes, such as Haskell [17]. Existential types [16, 3] are a formalization of the concept of an abstract data type, such as the package in Ada, the cluster in CLU, and the module in Modula2. By stating that a value has the existentially quantified type , we mean that has type for some fixed, but private type . Without ....

T. Nipkow and C. Prehofer. Type checking type classes. In Proc. 20th ACM Symp. Principles of Programming Languages, 1993.

....two kinds of functions, because predicates need not be continuous. Otherwise one could define X j F IX(P: P ) and derive the contradiction X :X. This problem can be solved using Isabelle s type classes, an overloading scheme similar to the one in the functional programming language Haskell [10, 13]. In Isabelle LCF we simply declare a new class cpo, which is the class of all domains. We can now restrict certain constants to be available only at types which are of class cpo: 8ff:cpo:ff, v : 8ff:cpo: ff; ff] o, F IX : 8ff:cpo: ff ff) ff. In all three cases the type variable ff ....

T. Nipkow and C. Prehofer. Type checking type classes. In Proc. 20th ACM Symp. Principles of Programming Languages, pages 409--418. ACM Press, 1993. Revised version to appear in J. Functional Programming.

....by ESPRIT BRA 6453, TYPES. 3 Research supported by the Deutsche Forschungsgemeinschaft (DFG) under grant Br 887 4, Deduktive Programmentwicklung. 4 Address: Institut fur Informatik, Technische Universitat Munchen, 80290 Munchen, Germany. Email: fnipkow,prehoferg informatik.tu muenchen.de 2 Tobias Nipkow and Christian Prehofer where the type variable ff ranges over all types. However, should not be applied to arguments of function type. To fix this problem, Standard ML (MTH90) introduces special type variables that range only over types where equality is defined. Equality differs from other polymorphic functions not ....

....the judgement : Ord has to be expanded to become : Eq : Ord, i.e. fEq; Ordg. However, it is almost easier to deal with subclasses directly than to eliminate them, as done in (NP93) To demonstrate this, and because subclasses are part of Haskell, we have included them in Mini Haskell. 4 Tobias Nipkow and Christian Prehofer 2.1 Sorts and Types As motivated in the introduction, sorts are finite sets of classes. This representation is a key ingredient for the concise treatment of type inference. Yet semantically the sort fC 1 ; Cng should be understood as C 1 : Cn . Thus fCg and C are equivalent, and ....

[Article contains additional citation context not shown here]

Tobias Nipkow and Christian Prehofer. Type checking type classes. In Proc. 20th ACM Symp. Principles of Programming Languages, pages 409--418. ACM Press, 1993.

No context found.

Tobias Nipkow and Christian Prehofer. Type checking type classes. In Proc. 20th ACM Symp. Principles of Programming Languages, pages 409--418, 1993.

No context found.

Tobias Nipkow and Christian Prehofer. Type checking type classes. In Proc. 20th ACM Symp. Principles of Programming Languages, pages 409--418.

No context found.

NP93. Tobias Nipkow and Christian Prehofer. Type checking type classes. In Conference Record of the Twentieth Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, Charleston, South Carolina, January 10-- 13, 1993, pages 409--418. ACM Press, January 1993.

First 50 documents

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