Results 1 - 10
of
11
Observable sharing for functional circuit description
- In Asian Computing Science Conference
, 1999
"... Pure functional programming languages have been proposed as a vehicle to describe, simulate and manipulate circuit specifications. We propose an extension to Haskell to solve a standard problem when manipulating data types representing circuits in a lazy functional language. The problem is that cir ..."
Abstract
-
Cited by 53 (3 self)
- Add to MetaCart
Pure functional programming languages have been proposed as a vehicle to describe, simulate and manipulate circuit specifications. We propose an extension to Haskell to solve a standard problem when manipulating data types representing circuits in a lazy functional language. The problem is that circuits are finite graphs -- but viewing them as an algebraic (lazy) datatype makes them indistinguishable from potentially infinite regular trees. However, implementations of Haskell do indeed represent cyclic structures by graphs. The problem is that the sharing of nodes that creates such cycles is not observable by any function which traverses such a structure. In this paper we propose an extension to call-by-need languages which makes graph sharing observable. The extension is based on non updatable reference cells and an equality test (sharing detection) on this type. We show that this simple and practical extension has well-behaved semantic properties, which means that many typical source-to-source program transformations, such as might be performed by a compiler, are still valid in the presence of this extension.
Composing contracts: an adventure in financial engineering - Functional Pearl
, 2000
"... Financial and insurance contracts do not sound like promising territory for functional programming and formal semantics, but in fact we have discovered that insights from programming languages bear directly on the complex subject of describing and valuing a large class of contracts. We introduce a ..."
Abstract
-
Cited by 46 (0 self)
- Add to MetaCart
Financial and insurance contracts do not sound like promising territory for functional programming and formal semantics, but in fact we have discovered that insights from programming languages bear directly on the complex subject of describing and valuing a large class of contracts. We introduce a combinator library that allows us to describe such contracts precisely, and a compositional denotational semantics that says what such contracts are worth. We sketch an implementation of our combinator library in Haskell. Interestingly, lazy evaluation plays a crucial role. 1 Introduction Consider the following nancial contract, C: the right to choose on 30 June 2000 between D1 Both of: D11 Receive $100 on 29 Jan 2001. D12 Pay $105 on 1 Feb 2002. D2 An option exercisable on 15 Dec 2000 to choose one of: D21 Both of: D211 Receive $100 on 29 Jan 2001. D212 Pay $106 on 1 Feb 2002. D22 Both of: D221 Receive $100 on 29 Jan 2001. D222 Pay $112 on 1 Feb 2003. The details of this contra...
Stretching the storage manager: weak pointers and stable names in Haskell
, 1999
"... . Every now and then, a user of the Glasgow Haskell Compiler asks for a feature that requires specialised support from the storage manager. Memo functions, pointer equality, external pointers, nalizers, and weak pointers, are all examples. We take memo functions as our exemplar because they turn ..."
Abstract
-
Cited by 34 (2 self)
- Add to MetaCart
(Show Context)
. Every now and then, a user of the Glasgow Haskell Compiler asks for a feature that requires specialised support from the storage manager. Memo functions, pointer equality, external pointers, nalizers, and weak pointers, are all examples. We take memo functions as our exemplar because they turn out to be the trickiest to support. We present no fewer than four distinct mechanisms that are needed to support memo tables, and that (in various combinations) satisfy a variety of other needs. The resulting set of primitives is undoubtedly powerful and useful. Whether they are too powerful is not yet clear. While the focus of our discussion is on Haskell, there is nothing Haskell-specic about most of the primitives, which could readily be used in other settings. 1 Introduction \Given an arbitrary function f, construct a memoised version of f; that is, construct a new function with the property that it returns exactly the same results as f, but if it is applied a second time to ...
Correctness of Monadic State: An Imperative Call-by-Need Calculus
- In Proc. 25th ACM Symposium on Principles of Programming Languages
, 1998
"... The extension of Haskell with a built-in state monad combines mathematical elegance with operational efficiency: ffl Semantically, at the source language level, constructs that act on the state are viewed as functions that pass an explicit store data structure around. ffl Operationally, at the imp ..."
Abstract
-
Cited by 20 (2 self)
- Add to MetaCart
The extension of Haskell with a built-in state monad combines mathematical elegance with operational efficiency: ffl Semantically, at the source language level, constructs that act on the state are viewed as functions that pass an explicit store data structure around. ffl Operationally, at the implementation level, constructs that act on the state are viewed as statements whose evaluation has the side-effect of updating the implicit global store in place. There are several unproven conjectures that the two views are consistent. Recently, we have noted that the consistency of the two views is far from obvious: all it takes for the implementation to become unsound is one judiciously-placed beta-step in the optimization phase of the compiler. This discovery motivates the current paper in which we formalize and show the correctness of the implementation of monadic state. For the proof, we first design a typed call-by-need language that models the intermediate language of the compiler, to...
How to Write a Financial Contract
"... valuation semantics. First, we will show how to translate an arbitrary contract, written in our language, into a value process, together with a handful of operations over these processes. These processes correspond directly to the mathematical and stochastic machinery used by nancial experts. ..."
Abstract
-
Cited by 16 (0 self)
- Add to MetaCart
valuation semantics. First, we will show how to translate an arbitrary contract, written in our language, into a value process, together with a handful of operations over these processes. These processes correspond directly to the mathematical and stochastic machinery used by nancial experts.
Monadic memoization mixins
, 2007
"... Memoization is a familiar technique for improving the performance of programs: computed answers are saved so that they can be reused later instead of being recomputed. In a pure functional language, memoization of a function is complicated by the need to manage the table of saved answers between cal ..."
Abstract
-
Cited by 4 (2 self)
- Add to MetaCart
(Show Context)
Memoization is a familiar technique for improving the performance of programs: computed answers are saved so that they can be reused later instead of being recomputed. In a pure functional language, memoization of a function is complicated by the need to manage the table of saved answers between calls to the function, includ-ing recursive calls within the function itself. A lazy recursive data structure can be used to maintain past answers — although achiev-ing an efficient algorithm can require a complex rewrite of the func-tion into a special form. Memoization can also be defined as a lan-guage primitive — but to be useful it would need to support a range of memoization strategies. In this paper we develop a technique for modular memoization within a pure functional language. We define monadic memoization mixins that are composed (via inheritance) with an ordinary monadic function to create a memoized version of the function. As a case study, we memoize a recursive-descent parser written using standard parser combinators. A comparison of the performance of different approaches shows that memoization mixins are efficient for a small example. 1.
A Memoizing Semantics for Functional Logic Languages
- IN PROC. ESOP 2004
, 2004
"... Declarative multi-paradigm languages combine the main features of functional and logic programming, like laziness, logic variables and non-determinism. The operational semantics of these languages is based on a combination of narrowing and residuation. In this article, we introduce a non-standar ..."
Abstract
-
Cited by 2 (1 self)
- Add to MetaCart
Declarative multi-paradigm languages combine the main features of functional and logic programming, like laziness, logic variables and non-determinism. The operational semantics of these languages is based on a combination of narrowing and residuation. In this article, we introduce a non-standard memoizing semantics for multi-paradigm declarative programs and prove its equivalence with the standard operational semantics. Both pure functional and pure logic programming have for long time taken advantage of tabling or memoizing schemes [15,19,7], which motivates the interest in the adapation of this technique to the integrated paradigm.
Function Inheritance: Monadic Memoization Mixins
"... Abstract. Inheritance is a mechanism for incrementally modifying recursive definitions. While inheritance is typically used in object-oriented languages, inheritance also has something to offer to functional programming. In this paper we illustrate the use of inheritance in a pure functional languag ..."
Abstract
- Add to MetaCart
(Show Context)
Abstract. Inheritance is a mechanism for incrementally modifying recursive definitions. While inheritance is typically used in object-oriented languages, inheritance also has something to offer to functional programming. In this paper we illustrate the use of inheritance in a pure functional language by developing a small library for memoization. We define monadic memoization mixins that compose—via inheritance—with an ordinary monadic function to create a memoized version of the function. A comparison of the performance of different approaches shows that memoization mixins are efficient for a small example. 1.
unknown title
, 2000
"... Abstract Financial and insurance contracts do not sound like promising territory for functional programming and formal semantics, but in fact we have discovered that insights from programming languages bear directly on the complex subject of describing and valuing a large class of contracts. We intr ..."
Abstract
- Add to MetaCart
(Show Context)
Abstract Financial and insurance contracts do not sound like promising territory for functional programming and formal semantics, but in fact we have discovered that insights from programming languages bear directly on the complex subject of describing and valuing a large class of contracts. We introduce a combinator library that allows us to describe such contracts precisely, and a compositional denotational semantics that says what such contracts are worth. We sketch an implementation of our combinator library in Haskell. Interestingly, lazy evaluation plays a crucial role. 1 Introduction Consider the following financial contract, C: the right to choose on 30 June 2000 between
unknown title
"... Memoization is a familiar technique for improving the performance of programs: computed answers are saved so that they can be reused later instead of being recomputed. In a pure functional language, memoization of a function is complicated by the need to manage the table of saved answers between cal ..."
Abstract
- Add to MetaCart
(Show Context)
Memoization is a familiar technique for improving the performance of programs: computed answers are saved so that they can be reused later instead of being recomputed. In a pure functional language, memoization of a function is complicated by the need to manage the table of saved answers between calls to the function, including recursive calls within the function itself. A lazy recursive data structure can be used to maintain past answers — although achieving an efficient algorithm can require a complex rewrite of the function into a special form. Memoization can also be defined as a language primitive — but to be useful it would need to support a range of memoization strategies. In this paper we develop a technique for modular memoization within a pure functional language. We define monadic memoization mixins that are composed (via inheritance) with an ordinary monadic function to create a memoized version of the function. As a case study, we memoize a recursive-descent parser written using standard parser combinators. A comparison of the performance of different approaches shows that memoization mixins are efficient for a small example. 1.
