Results 11 - 20
of
29
When Will Deforestation Stop?
- In 1988 Glasgow Workshop on Functional Programming
, 1988
"... A compositional style of programming is often advocated by functional programmers. However, there is a certain efficiency penalty involved in creating the requisite intermediate structures. Deforestation is a program transformation technique which removes such structures for some such programs. This ..."
Abstract
-
Cited by 21 (1 self)
- Add to MetaCart
A compositional style of programming is often advocated by functional programmers. However, there is a certain efficiency penalty involved in creating the requisite intermediate structures. Deforestation is a program transformation technique which removes such structures for some such programs. This paper is an investigation into the issues of termination of the transformation process. 1
Deforestation for Higher-Order Functional Programs
, 1995
"... Functional programming languages are an ideal medium for program optimisations based on source-to-source transformation techniques. Referential transparency affords opportunities for a wide range of correctness-preserving transformations leading to potent optimisation strategies. This thesis builds ..."
Abstract
-
Cited by 17 (0 self)
- Add to MetaCart
Functional programming languages are an ideal medium for program optimisations based on source-to-source transformation techniques. Referential transparency affords opportunities for a wide range of correctness-preserving transformations leading to potent optimisation strategies. This thesis builds on deforestation, a program transformation technique due to Wadler that removes intermediate data structures from first-order functional programs. Our contribution is to reformulate deforestation for higher-order functional programming languages, and to show that the resulting algorithm terminates given certain syntactic and typing constraints on the input. These constraints are entirely reasonable, indeed it is possible to translate any typed program into the required syntactic form. We show how this translation can be performed automatically and optimally. The higher-order deforestation algorithm is transparent. That is, it is possible to determine by examination of the source program w...
A Co-iterative Characterization of Synchronous Stream Functions
, 1997
"... This paper presents an attempt to characterize synchronous stream functions within the framework of co-iteration and to use this characterization in building a compiler for (higher order and recursive) synchronous data-flow programs. First length-preserving functions are considered and we show that ..."
Abstract
-
Cited by 16 (3 self)
- Add to MetaCart
This paper presents an attempt to characterize synchronous stream functions within the framework of co-iteration and to use this characterization in building a compiler for (higher order and recursive) synchronous data-flow programs. First length-preserving functions are considered and we show that streams equipped with such functions form a Cartesian-closed category. Then this point of view is extended toward non length-preserving ones and we stress the use of "empty" values in handling this case. Finally, the implementation we did of this material in a synchronous stream package built on top of an ML-like language is briefly described.
Realtime Signal Processing -- Dataflow, Visual, and Functional Programming
, 1995
"... This thesis presents and justifies a framework for programming real-time signal processing systems. The framework extends the existing "block-diagram" programming model; it has three components: a very high-level textual language, a visual language, and the dataflow process network model of computat ..."
Abstract
-
Cited by 13 (1 self)
- Add to MetaCart
This thesis presents and justifies a framework for programming real-time signal processing systems. The framework extends the existing "block-diagram" programming model; it has three components: a very high-level textual language, a visual language, and the dataflow process network model of computation. The dataflow process network model, although widely-used, lacks a formal description, and I provide a semantics for it. The formal work leads into a new form of actor. Having established the semantics of dataflow processes, the functional language Haskell is layered above this model, providing powerful features---notably polymorphism, higher-order functions, and algebraic program transformation---absent in block-diagram systems. A visual equivalent notation for Haskell, Visual Haskell, ensures that this power does not exclude the "intuitive" appeal of visual interfaces; with some intelligent layout and suggestive icons, a Visual Haskell program can be made to look very like a block dia...
A Functional Extension To Lustre
, 1995
"... Lustre is a data-flow programming language for reactive purposes, which has been given a synchronous operational semantic. Static checks called "clock calculus" restrict Lustre programs to those data-flow networks which can be executed synchronously. As a by-product of this restriction, Lustre progr ..."
Abstract
-
Cited by 5 (1 self)
- Add to MetaCart
Lustre is a data-flow programming language for reactive purposes, which has been given a synchronous operational semantic. Static checks called "clock calculus" restrict Lustre programs to those data-flow networks which can be executed synchronously. As a by-product of this restriction, Lustre programs enjoy efficient compiling techniques. Yet, due to its reactive origin, Lustre applies only to static networks. We show here, that both this operational semantic, and clock calculus can be extended toward accounting for general functional features : abstraction, application and recursion. This allows us to give sense to both higher order, and dynamical synchronous data-flow networks, which can thus be expected to share the same efficient compiling techniques. 1. Introduction 1.1. Some milestones in data-flow programming In the seventies, the Lucid language was proposed 2;1 as a way of overcoming the lack of efficency of functional languages by providing them with stream based iteration...
Making Mercury Programs Tail Recursive
- In Procs. of LOPSTR99, LNCS 1817
, 1999
"... . We present two optimizations for making Mercury programs tail recursive. Both operate by taking computations that occur after a recursive call and moving them before the recursive call, modifying them as necessary. The rst optimization moves calls to associative predicates; it is a pure source ..."
Abstract
-
Cited by 4 (3 self)
- Add to MetaCart
. We present two optimizations for making Mercury programs tail recursive. Both operate by taking computations that occur after a recursive call and moving them before the recursive call, modifying them as necessary. The rst optimization moves calls to associative predicates; it is a pure source to source transformation. The second optimization moves construction unications; it required extensions to the mode system (to record aliases) and to the parameter passing convention (to allow arguments to be returned in memory). The two optimizations are designed to work together, and can make a large class of programs tail recursive. 1 Introduction Recursive calls are often very close to being the last action in a clause. Frequently, however, the recursive call computes a value which must be put into a memory cell or used in a simple computation. Since the Mercury execution algorithm [13] requires both of these kinds of actions to be performed after the call, such clauses are not ...
Optimizing Algebraic Programs
, 1994
"... This paper considers a programming language where all control is encoded in algebras ..."
Abstract
-
Cited by 4 (1 self)
- Add to MetaCart
This paper considers a programming language where all control is encoded in algebras
Precise and Expressive Mode Systems for Typed Logic Programming Languages
, 2003
"... In this thesis we look at mode analysis of logic programs. Being based on the mathematical formalism of predicate logic, logic programs have no a priori notion of data flow --- a single logic program may run in multiple modes where each mode describes, or prescribes, a pattern of data flow. ..."
Abstract
-
Cited by 3 (0 self)
- Add to MetaCart
In this thesis we look at mode analysis of logic programs. Being based on the mathematical formalism of predicate logic, logic programs have no a priori notion of data flow --- a single logic program may run in multiple modes where each mode describes, or prescribes, a pattern of data flow.
Eliminating Intermediate Lists in pH using Local Transformations
- MASSACHUSETTS INSTITUTE OF TECHNOLOGY
, 1994
"... The extensive use of lists in functional programming languages exacts a cost penalty for important operations such as array construction. In addition, because lists are linear data structures, it is difficult to generate and traverse them efficiently in parallel given a purely-functional environment ..."
Abstract
-
Cited by 3 (1 self)
- Add to MetaCart
The extensive use of lists in functional programming languages exacts a cost penalty for important operations such as array construction. In addition, because lists are linear data structures, it is difficult to generate and traverse them efficiently in parallel given a purely-functional environment. Three common methods of traversal---left and right fold, and reduction---can be described in terms of map and reduce operations yielding higher-order functions; these higher-order functions can be represented entirely at compile time. This thesis examines this representation of list traversal, describes its implementation in the desugaring phase of the compiler for pH (an implicitly-parallel, mostly-functional dialect of the language Haskell). This approach to desugaring gives rise to a set of rules for compiling list comprehensions efficiently, and to a pair of functions unfold and synthesize which can be immediately eliminated if the lists they generate are traversed by folding or reduc...
Towards Leakage Containment
, 1992
"... Functional programs are organized into procedures, each encapsulating a specific task. A procedure should not cause its callers to repeat its work. This forced repetition of work we call leakage. In this paper we describe several common instances of leakage, and show how they can be eliminated usin ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
Functional programs are organized into procedures, each encapsulating a specific task. A procedure should not cause its callers to repeat its work. This forced repetition of work we call leakage. In this paper we describe several common instances of leakage, and show how they can be eliminated using an extension of continuation-passing style. 1 Introduction A goal of programming is to divide a complex task into simpler parts. In a well organized program each of these simpler tasks is represented by a procedure. Each procedure should perform a distinct action. Its user should not have to be conscious about the details of its implementation and should not have to undo or repeat work performed by it. This excess interaction between procedures is called leakage. When leakage is eliminated, the clarity and correctness of programs is enhanced. Our goal in this paper is to show how some leakage can be removed by using a generalization of continuation-passing style. We emphasize the developm...

