Type classes with existential types

Läufer, Konstantin

doi:10.1017/s0956796800001817

Cited by 33 publications

(10 citation statements)

References 25 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…to find a workaround for the fact that higher order logic is inconsistent with System F [14]. An initial step in this direction would be the support for existential types, which provide a clean way of encapsulating representations of abstract datatypes [37]. Concerning the HasCasl development methodology (and indeed any methodology that works with standard logics on non-continuous functions to specify higher order programs), an open problem is support for developments that start with an abstract algebraic specification and only later refine this to a design specification working with cpo's and continuous functions.…”

Section: Discussionmentioning

confidence: 99%

HasCasl: Integrated higher-order specification and program development

Schröder

Mossakowski

2009

Theoretical Computer Science

View full text Add to dashboard Cite

a b s t r a c tWe lay out the design of HasCasl, a higher order extension of the algebraic specification language Casl that serves both as a wide-spectrum language for the rigorous specification and development of software, in particular but not exclusively in modern functional programming languages, and as an expressive standard language for higher-order logic. Distinctive features of HasCasl include partial higher order functions, higher order subtyping, shallow polymorphism, and an extensive type-class mechanism. Moreover, HasCasl provides dedicated specification support for monad-based functional-imperative programming with generic side effects, including a monad-based generic Hoare logic. IntroductionThe rigorous development of software from abstract requirements to executable code calls for wide-spectrum languages that are sufficiently powerful and flexible to support both an expressive specification logic and concepts appearing in advanced programming languages, including modern functional languages such as Haskell [59], but also imperative and object-oriented languages. Here, we discuss the design of such a wide-spectrum language, HasCasl. HasCasl is an extension of the standard algebraic specification language Casl (Common Algebraic Specification Language) [6,53] developed by the Common Framework Initiative (CoFI) of IFIP WG 1.3, and as such has been adopted by IFIP WG 1.3. It arguably constitutes 'the' natural higher order extension of Casl, and is intended, beyond its purpose as a software specification language, as an expressive standard language for higher order logic. In particular, HasCasl is presently the most expressive language in the logic graph underlying the Bremen heterogeneous tool set Hets [48] and as such serves as a central hub for the interchange of theories between various formalisms in the tool.The core of HasCasl is a higher order logic of partial functions built on top of Moggi's partial λ-calculus [44]. The semantics and proof theory of this logic have been developed in a companion paper [76]; essentially, one arrives at an intuitionistic partial higher order logic without choice principles (even without unique choice). The full HasCasl logic extends the core logic by subtyping and type-classed based shallow polymorphism, including higher-order type constructors and constructor classes; the semantics of the latter is based on models explicitly incorporating signature extensions [70]. Support for general recursive functions is bootstrapped in the style of HOLCF [64] by specifying a theory of fixed point recursion on complete partial orders. Extensive syntactical sugaring of these concepts yields an executable sublanguage which is in close correspondence with a large subset of Haskell.Part of the technical difficulties arising in the development of these concepts stems from the above-mentioned lack of unique choice in the core logic; in particular, additional effort is required in the construction of inductive datatypes and in setting up the theory of complete partial orders. We beli...

show abstract

Section: Discussionmentioning

confidence: 99%

HasCasl: Integrated higher-order specification and program development

Schröder

Mossakowski

2009

Theoretical Computer Science

View full text Add to dashboard Cite

show abstract

“…Without polymorphic variants, we have to represent heterogeneous lists using existential types [17], which also leads to loss of information.…”

Section: Related Workmentioning

confidence: 99%

Polymorphic variants in Haskell

Kagawa

2006

Proceedings of the 2006 ACM SIGPLAN Workshop on Haskell

View full text Add to dashboard Cite

In languages that support polymorphic variants, a single variant value can be passed to many contexts that accept different sets of constructors. Polymorphic variants can be used in order to introduce extensible algebraic datatypes into functional programming languages and are potentially useful for application domains such as interpreters, graphical user interface (GUI) libraries and database interfaces, where the number of necessary constructors cannot be determined in advance. Very few functional languages, however, have a mechanism to extend existing datatypes by adding new constructors. In general, for polymorphic variants to be useful, we would need some mechanisms to reuse existing functions and extend them for new constructors.Actually, the type system of Haskell, when extended with parametric type classes (or multi-parameter type classes with functional dependencies), has enough power not only to mimic polymorphic variants but also to extend existing functions for new constructors. This paper, first, explains how to do this in Haskell's type system (Haskell 98 with popular extensions). However, this encoding of polymorphic variants is difficult to use in practice. This is because it is quite tedious for programmers to write mimic codes by hand and because the problem of ambiguous overloading resolution would embarrass programmers. Therefore, the paper proposes an extension of Haskell's type classes that supports polymorphic variants directly. It has a novel form of instance declarations where records and variants are handled symmetrically.This type system can produce vanilla Haskell codes as a result of type inference. Therefore it behaves as a preprocessor which translates the extended language into plain Haskell. Programmers would be able to use polymorphic variants without worrying nasty problems such as ambiguities.

show abstract

“…Technically, we define a type class Display, which defines the operations that a display has to implement, for example creating and updating objects, generating command events (DispCmd), and receiving display message events (DispMsg): All displays are kept in one heterogeneous list (using existential types [22]): display events are sent to all elements of this list, and the command events generated by all displays are the command events of each display combined with the obvious extension of the binary choice operator (+>) to lists of events. Notice that implementing a notion of object within the interface allows us to keep context information with objects which specifies dependencies: effectively, a position within the linear PGIP protocol.…”

Section: Display Enginesmentioning

confidence: 99%

Proof General meets IsaWin

Aspinall¹,

Lüth²

2004

Electronic Notes in Theoretical Computer Science

View full text Add to dashboard Cite

We describe the design and prototype implementation of a combination of theorem prover interface technologies. On one side, we take from Proof General the idea of a prover-independent interaction language and its proposed implementation within the PG Kit middleware architecture. On the other side, we take from IsaWin a sophisticated graphical metaphor using direct manipulation for developing proofs. We believe that the resulting system will provide a powerful, robust and generic environment for developing proofs within interactive proof assistants that also opens the way for studying and implementing new mechanisms for managing interactive proof development.

show abstract

Type classes with existential types

Cited by 33 publications

References 25 publications

HasCasl: Integrated higher-order specification and program development

HasCasl: Integrated higher-order specification and program development

Polymorphic variants in Haskell

Proof General meets IsaWin

Contact Info

Product

Resources

About