Results 1 -
8 of
8
A Generic Programming Extension for Haskell
- Utrecht University
, 1999
"... Many functions can be dened completely generically for all datatypes. Examples include pretty printers (eg show), parsers (eg read), data converters, equality and comparison functions, mapping functions, and so forth. This paper proposes a generic programming extension that enables the user to dene ..."
Abstract
-
Cited by 39 (5 self)
- Add to MetaCart
Many functions can be dened completely generically for all datatypes. Examples include pretty printers (eg show), parsers (eg read), data converters, equality and comparison functions, mapping functions, and so forth. This paper proposes a generic programming extension that enables the user to dene such functions in Haskell. In particular, the proposal aims at generalizing Haskell's deriving construct, which is commonly considered decient since instance declarations can only be derived for a few predened classes. Using generic denitions derived instances can be specied for arbitrary user-dened type classes and for classes that abstract over type constructors of rst-order kind. 1 Introduction Generic or polytypic programming aims at relieving the programmer from repeatedly writing functions of similar functionality for dierent datatypes. Typical examples for socalled generic functions include pretty printers (eg show), parsers (eg read), functions that convert data into a u...
Lightweight Extensible Records for Haskell
, 1999
"... Early versions of Haskell provied only a positional notation to build and take apart user-defined datatypes. This positional notation is awkward and error-prone when dealing with datatypes that have more than a couple of components, so later versions of Haskell introduced a mechanism for labeled fie ..."
Abstract
-
Cited by 20 (0 self)
- Add to MetaCart
Early versions of Haskell provied only a positional notation to build and take apart user-defined datatypes. This positional notation is awkward and error-prone when dealing with datatypes that have more than a couple of components, so later versions of Haskell introduced a mechanism for labeled fields that allows components to be set and extracted by name. While this has been useful in practice, it also has several significant problems; for example, no field name can be used in more than one datatype. In this paper, we present a concrete proposal for replacing the labeled-field mechanisms of Haskell 98 with a more flexible system of records that avoids the problems mentioned above. With a theoretical foundation in the earlier work of Gaster and Jones, our system offers lightweight, extensible records and a complement of polymorphic operations for manipulating them. On a more concrete level, our proposal is a direct descendent of the Trex implementation ("typed records with extensibility") i...
Meta-programming with Built-in Type Equality (Extended Abstract)
, 2004
"... Tim Sheard sheard@cse.ogi.edu Emir Pasalic + pasalic@cse.ogi.edu ABSTRACT We report our experience with exploring a new point in the design space for formal reasoning systems: the development of the programming language##ngu .##209 is intended as both a practical programming language and ..."
Abstract
-
Cited by 15 (2 self)
- Add to MetaCart
Tim Sheard sheard@cse.ogi.edu Emir Pasalic + pasalic@cse.ogi.edu ABSTRACT We report our experience with exploring a new point in the design space for formal reasoning systems: the development of the programming language##ngu .##209 is intended as both a practical programming language and a logic. The main goal of##102 is to allow programmers to describe and reason about semantic properties of programs from within the programming language itself, mainly by using a powerful type system.
Exploring the Design Space for Type-based Implicit Parameterization
- Proceedings of Supercomputing '97
, 1999
"... A common task in programming is to arrange for data to be passed from the point where it first becomes available to the places where it is needed, which may be much further down the call hierarchy. One approach is to store the data in a global variable. Another alternative is to add extra parame ..."
Abstract
-
Cited by 8 (1 self)
- Add to MetaCart
A common task in programming is to arrange for data to be passed from the point where it first becomes available to the places where it is needed, which may be much further down the call hierarchy. One approach is to store the data in a global variable. Another alternative is to add extra parameters at each level to thread it from the point of supply to the point of use. Neither of these is particularly attractive: The former is inflexible, while the latter requires modification of the program text, adding auxiliary parameters to each function definition and call. This paper explores the design space for a third alternative, using types to direct the introduction and use of implicit parameters and so carry data from supply to use. This gives the flexibility of parameterization without the burden of adding parameters by hand. The most general point in the design space uses relations on types to support sophisticated forms of overloading, and includes several known systems ...
Haxcel: A Spreadsheet Interface to Haskell
- Pages 206–222 of: 14th Int. Workshop on the Implementation of Functional Languages
, 2002
"... Abstract. The spreadsheet paradigm offers a fast interactive loop, where the effects of updates to definitions and data are immediately visible. This makes the paradigm attractive for program development, where redefinitions can be immediately tested and the results displayed. We have designed a sim ..."
Abstract
-
Cited by 3 (0 self)
- Add to MetaCart
Abstract. The spreadsheet paradigm offers a fast interactive loop, where the effects of updates to definitions and data are immediately visible. This makes the paradigm attractive for program development, where redefinitions can be immediately tested and the results displayed. We have designed a simple, compilerindependent spreadsheet interface to Haskell, where cells host Haskell definitions. Spreadsheets are also used for high-level array calculations. In order to meet that demand we have designed and implemented an extended array library for Haskell, which provides a number of typical array-language facilities. Together, the interface and the array library provide an interactive environment that can be used both for development of general Haskell code and for array-oriented spreadsheet calculations.
A Graphical Development Environment for Functional Logic Languages
- Universidad Politécnica de Valencia
, 2000
"... In this paper we present an Integrated Development Environment based on the Programming Environment that support the Functional Logic languages selected: Curry and TOY. The environment has been built using the Tcl/Tk language. The main feature of this environment is its portability, as we show the e ..."
Abstract
-
Cited by 3 (0 self)
- Add to MetaCart
In this paper we present an Integrated Development Environment based on the Programming Environment that support the Functional Logic languages selected: Curry and TOY. The environment has been built using the Tcl/Tk language. The main feature of this environment is its portability, as we show the environment can support, with little changes, different functional and/or logic languages. Another interesting feature is that it can be programmed in some of those languages (Curry, Haskell, Prolog,. . . ) in a pure declarative way using their graphic user interface libraries. Moreover, the design of the environment has been done taking special care of the reusability aspect, following modern component-based programming approaches.
Reasoning about Selective Strictness -- Operational Equivalence, Heaps and Call-by-Need Evaluation, New Inductive Principles
, 2009
"... Many predominantly lazy languages now incorporate strictness enforcing primitives, for example a strict let or sequential composition seq. Reasons for doing this include gains in time or space efficiencies, or control of parallel evaluation. This thesis studies how to prove equivalences between pro ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
Many predominantly lazy languages now incorporate strictness enforcing primitives, for example a strict let or sequential composition seq. Reasons for doing this include gains in time or space efficiencies, or control of parallel evaluation. This thesis studies how to prove equivalences between programs in languages with selective strictness, specifically, we use a restricted core lazy functional language with a selective strictness operator seq whose operational semantics is a variant of one considered by van Eckelen and de Mol, which itself was derived from Launchbury’s natural semantics for lazy evaluation. The main research contributions are as follows: We establish some of the first ever equivalences between programs with selective strictness. We do this by manipulating operational semantics derivations, in
Reasoning about Selective Strictness -- Operational Equivalence, Heaps and Call-by-Need Evaluation, New Inductive Principles
, 2009
"... This thesis studies how to prove equivalences between programs in languages with selective strictness, specifically, we use a restricted core lazy functional language with a selective strictness operator seq. We establish some of the first ever equivalences between lazy programs with selective str ..."
Abstract
- Add to MetaCart
This thesis studies how to prove equivalences between programs in languages with selective strictness, specifically, we use a restricted core lazy functional language with a selective strictness operator seq. We establish some of the first ever equivalences between lazy programs with selective strictness by manipulating operational semantics derivations. Our operational semantics is similar to that used by van Eekelen and De Mol, though we introduce a ‘garbage-collecting’ rule for (let) which turns out to cause expressiveness restrictions. For example, arguably reasonable lazy programs such as let y = λz.z in λx.y do not reduce in our operational semantics. We prove some properties of seq, including associativity, idempotence, and left-commutativity. The proofs use our three notions of program equivalence defined

