Results 11  20
of
43
Axioms for Recursion in CallbyValue
 HIGHERORDER AND SYMBOLIC COMPUT
, 2001
"... We propose an axiomatization of fixpoint operators in typed callbyvalue programming languages, and give its justifications in two ways. First, it is shown to be sound and complete for the notion of uniform Tfixpoint operators of Simpson and Plotkin. Second, the axioms precisely account for Filins ..."
Abstract

Cited by 11 (5 self)
 Add to MetaCart
We propose an axiomatization of fixpoint operators in typed callbyvalue programming languages, and give its justifications in two ways. First, it is shown to be sound and complete for the notion of uniform Tfixpoint operators of Simpson and Plotkin. Second, the axioms precisely account for Filinski's fixpoint operator derived from an iterator (infinite loop constructor) in the presence of firstclass continuations, provided that we define the uniformity principle on such an iterator via a notion of effectfreeness (centrality). We then explain how these two results are related in terms of the underlying categorical structures.
A Recursive do for Haskell
, 2002
"... Certain programs making use of monads need to perform recursion over the values of monadic actions. Although the donotation of Haskell provides a convenient framework for monadic programming, it lacks the generality to support such recursive bindings. In this paper, we describe an enhanced translat ..."
Abstract

Cited by 10 (1 self)
 Add to MetaCart
Certain programs making use of monads need to perform recursion over the values of monadic actions. Although the donotation of Haskell provides a convenient framework for monadic programming, it lacks the generality to support such recursive bindings. In this paper, we describe an enhanced translation schema for the donotation and its integration into Haskell. The new translation allows variables to be bound recursively, provided the underlying monad comes equipped with an appropriate fixedpoint operator.
Semantics of value recursion for monadic input/output
 Journal of Theoretical Informatics and Applications
, 2002
"... Abstract. Monads have been employed in programming languages for modeling various language features, most importantly those that involve side effects. In particular, Haskell’s IO monad provides access to I/O operations and mutable variables, without compromising referential transparency. Cyclic defi ..."
Abstract

Cited by 7 (1 self)
 Add to MetaCart
Abstract. Monads have been employed in programming languages for modeling various language features, most importantly those that involve side effects. In particular, Haskell’s IO monad provides access to I/O operations and mutable variables, without compromising referential transparency. Cyclic definitions that involve monadic computations give rise to the concept of valuerecursion, where the fixedpoint computation takes place only over the values, without repeating or losing effects. In this paper, we describe a semantics for a lazy language based on Haskell, supporting monadic I/O, mutable variables, usual recursive definitions, and value recursion. Our semantics is composed of two layers: A natural semantics for the functional layer, and a labeled transition semantics for the IO layer. Mathematics Subject Classification. 68N18, 68Q55, 18C15.
Recursion is a Computational Effect
, 2000
"... In a recent paper, Launchbury, Lewis, and Cook observe that some Haskell applications could benefit from a combinator mfix for expressing recursion over monadic types. We investigate three possible definitions of mfix and implement them in Haskell. Like traditional fixpoint operators, there are ..."
Abstract

Cited by 7 (1 self)
 Add to MetaCart
In a recent paper, Launchbury, Lewis, and Cook observe that some Haskell applications could benefit from a combinator mfix for expressing recursion over monadic types. We investigate three possible definitions of mfix and implement them in Haskell. Like traditional fixpoint operators, there are two approaches to the definition of mfix: an unfolding one based on mathematical semantics, and an updating one based on operational semantics. The two definitions are equivalent in pure calculi but have different behaviors when used within monads. The unfolding version can be easily defined in Haskell if one restricts fixpoints to function types. The updating version is much more challenging to define in Haskell despite the fact that its definition is straightforward in Scheme. After studying the Scheme definition in detail, we mirror it in Haskell using the primitive unsafePerformIO. The resulting definition of mfix appears to work well but proves to be unsafe, in the sense that i...
Traced Premonoidal Categories
, 1999
"... Motivated by some examples from functional programming, we propose a generalization of the notion of trace to symmetric premonoidal categories and of Conway operators to Freyd categories. We show that in a Freyd category, these notions are equivalent, generalizing a wellknown theorem relating trace ..."
Abstract

Cited by 7 (0 self)
 Add to MetaCart
Motivated by some examples from functional programming, we propose a generalization of the notion of trace to symmetric premonoidal categories and of Conway operators to Freyd categories. We show that in a Freyd category, these notions are equivalent, generalizing a wellknown theorem relating traces and Conway operators in cartesian categories.
Just do it: Simple monadic equational reasoning
 In Proceedings of the 16th International Conference on Functional Programming (ICFP’11
, 2011
"... One of the appeals of pure functional programming is that it is so amenable to equational reasoning. One of the problems of pure functional programming is that it rules out computational effects. Moggi and Wadler showed how to get round this problem by using monads to encapsulate the effects, leadin ..."
Abstract

Cited by 6 (1 self)
 Add to MetaCart
One of the appeals of pure functional programming is that it is so amenable to equational reasoning. One of the problems of pure functional programming is that it rules out computational effects. Moggi and Wadler showed how to get round this problem by using monads to encapsulate the effects, leading in essence to a phase distinction—a pure functional evaluation yielding an impure imperative computation. Still, it has not been clear how to reconcile that phase distinction with the continuing appeal of functional programming; does the impure imperative part become inaccessible to equational reasoning? We think not; and to back that up, we present a simple axiomatic approach to reasoning about programs with computational effects.
Semantics of fixIO
, 2001
"... Recent work on recursion over the values of monadic actions resulted in the introduction of a family of fixed point operators, one for each di#erent kind of monadic e#ect. In the context of Haskell, the function fixIO is the corresponding operator for the IO monad. Unfortunately, both the IO monad a ..."
Abstract

Cited by 6 (3 self)
 Add to MetaCart
Recent work on recursion over the values of monadic actions resulted in the introduction of a family of fixed point operators, one for each di#erent kind of monadic e#ect. In the context of Haskell, the function fixIO is the corresponding operator for the IO monad. Unfortunately, both the IO monad and fixIO are language primitives in Haskell, i.e. they can not be defined within the language itself. Therefore, any attempt to formally reason about fixIO is futile without a precise semantics for computations in the IO monad. Quite recently, Peyton Jones introduced an operational semantics based on observable transitions as a method for reasoning about I/O in Haskell. Building on this work, we show how one can model fixIO as well, and we argue that it indeed belongs to the family of fixed point operators that enable monadic value recursion.
Mixin modules, modules and extended value binding in a callbyvalue setting
, 2003
"... Mixin modules, modules and extended value binding ..."
Hardware Design with Generalized Arrows
"... Abstract. Instances of the GArrow type class (Figure 2) are called generalized arrows. The GArrow class generalizes Control.Arrow by allowing any typelevel monoid to take the place of the cartesian product (,) and by replacing arr with the “structural ” functions usually defined in terms of it. Mul ..."
Abstract

Cited by 1 (0 self)
 Add to MetaCart
Abstract. Instances of the GArrow type class (Figure 2) are called generalized arrows. The GArrow class generalizes Control.Arrow by allowing any typelevel monoid to take the place of the cartesian product (,) and by replacing arr with the “structural ” functions usually defined in terms of it. Multilevel terms with environment classifier types [TN03] may be flattened into singlelevel terms parameterized by an instance of the GArrow class. Multilevel terms and environment classifier types play the same role for generalized arrows that Paterson notation [Pat01] and its typing rules [PPJ] play for Control.Arrow. This paper presents the first nontrivial application of generalized arrows. Previously, GHC had been extended 1 with environment classifiers and an additional compiler pass which implements the flattening transformation [Meg11]. In the present work this facility has been augmented to allow for programs in which level0 terms consist of unrestricted Haskell, while
Practical aspects of multistage programming, rice University
, 2004
"... Abstract. Highlevel languages offer abstraction mechanisms that can reduce development time and improve software quality. But abstraction mechanisms often have an accumulative runtime overhead that can discourage their use. Multistage programming (MSP) languages offer constructs that make it possi ..."
Abstract

Cited by 1 (0 self)
 Add to MetaCart
Abstract. Highlevel languages offer abstraction mechanisms that can reduce development time and improve software quality. But abstraction mechanisms often have an accumulative runtime overhead that can discourage their use. Multistage programming (MSP) languages offer constructs that make it possible to use abstraction mechanisms without paying a runtime overhead. This paper studies applying MSP to implementing dynamic programming (DP) problems. The study reveals that staging highlevel implementations of DP algorithms naturally leads to a code explosion problem. In addition, it is common that highlevel languages are not designed to deliver the kind of performance that is desirable in implementations of such algorithms. The paper proposes a solution to each of these two problems. Staged memoization is used for code explosion, and a kind of “offshoring ” translation is used to address the second. For basic DP problems, the performance of the resulting specialized C implementations is almost always better than the handwritten generic C implementations. 1