Roger Hoover. "Alphonse: Incremental Computation as a Programming Abstraction". Sigplan Notices 27, 7 (July 1992), 261-272. ACM SIGPLAN'92 Conference on Programming Language Design and Implementation.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....results used in computing the output f(x) also need to be maintained for efficient incremental computation of f(x Phi y) Moreover, certain auxiliary information about x may need to be discovered and maintained as well. Numerous techniques for incremental computation have been developed, e.g. [3, 4, 16, 20, 21, 24, 31, 36, 38, 40, 43, 44, 47, 52]. In [31] we give a systematic transformational approach for deriving an incremental program f from a given program f and an input change Phi. The basic idea is to identify in the computation of f(x Phi y) those subcomputations that are also performed in the computation of f(x) and whose ....

.... function calls [39, 40] saving results of intermediate reductions at appointed places [16] maintaining the change detailing network of INC [52] keeping residual programs for certain input partitions [47] and maintaining intermediate results and dependencies identified by Alphonse annotations [20]. In [30] we have given a cache and prune method to statically transform programs to cache all kinds of intermediate results needed for incremental computation. The basic idea is to (I) extend the program f to a program f that returns all intermediate results, II) incrementalize the program f ....

R. Hoover. Alphonse: Incremental computation as a programming abstraction. In Proceedings of the ACM SIGPLAN '92 Conference on PLDI, pages 261--272, California, June 1992.

....value during the traversal indicates change status directly. The scheme described so far is unrealistically pessimistic in that it will re evaluate every call to a functional attribute that is transitively dependent upon a changed scalar attribute. By caching the 1 This term is used by Hoover [37] in exactly the same sense as we use it here. We chose it in analogy to the maintained properties of Ballance s Colander system [4] which inspired many aspects of the present work. 78 argument result pairs observed at each function attribute, it can be determined when the observed mapping has ....

....programs apart from attribute grammars. In common with Swierstra and Vogt, cache housekeeping is not adequately addressed, permitting the cache to contain stale entries, or entries that were flushed prematurely and must be unnecessarily regenerated. Hoover s Alphonse program transformation system [37] pioneered the combination of topologicalorder change propagation and function caching. In response to user supplied annotations, calls to functions and methods in an imperative object oriented language can be cached to permit efficient incremental execution. Because Alphonse supports unrestricted ....

Roger Hoover. Alphonse: Incremental computation as a programming abstraction. In Proceedings of the ACM SIGPLAN '92 Conference on Programming Language Design and Implementation, pages 261--272, 1992.

.... computation is a fundamental issue relevant throughout computer software, e.g. optimizing compilers [2,3,17,23,78] transformational program development [8,20,62,65,77] and interactive systems [5,6,10,22,33,41,71,72] Numerous techniques for incremental computation have been developed, e.g. [3,4,25,34 36,56,64,68,70,73,76,79,86]. Strengthening invariants for incrementalization. We are engaged in an ambitious e ort to derive incremental extended programs automatically (or semi automatically) from non incremental programs written in standard programming languages.This approach contrasts with many other approaches that aim ....

R. Hoover. Alphonse: Incremental computation as a programming abstraction. In Proceedings of the ACM SIGPLAN '92 Conference on Programming Language Design and Implementation, pages 261-272. ACM, New York, June 1992.

....to run in such a framework without deriving explicit incremental algorithms. Examples are incremental attribute evaluation framework [72, 73] function caching [67] incremental lambda reduction [25, 1] traditional partial evaluation [80] change detailing network [87] and program abstraction [38]. Each such framework provides some language for describing application programs, defines the classes of input changes that the framework can handle, and uses a particular incremental algorithm to handle the input changes. Any input change to an application program is mapped to a change that the ....

R. Hoover. Alphonse: Incremental computation as a programming abstraction. In Proceedings of the ACM SIGPLAN '92 Conference on Programming Language Design and Implementation, pages 261--272. ACM, New York, June 1992.

.... and Hudson 1988; Hudson 1994; Szekely and Myers 1988; Vander Zanden 1988; Myers 1990; Hill et al. 1994] graphical layout systems [Gosling 1983] simulation systems [Borning 1981; Borning and Duisberg 1986] animations [Duisberg 1986] programming languages [Freeman Benson 1990; Maloney 1991; Hoover 1992], and programming environments [Reps et al. 1983] For instance, they may be used by: a graphical layout system to specify the alignment of objects; a graphical interface toolkit to maintain consistency between application data and the graphical objects used to display this data; a ....

....version of this technique are the novel contributions of this paper. The execution phase may use any of the existing one way constraint QuickPlan 6 satisfaction algorithms, including both eager evaluators [Vander Zanden et al. 1994; Alpern et al. 1990; Reps et al. 1983; Hoover 1987; Hoover 1992] and lazy evaluators [Vander Zanden et al. 1994; Hudson 1991; Barth 1986] The paper is organized as follows. Sections 2 discuss why dataflow constraints are important. Section 3 presents a formulation of the constraint satisfaction problem as a graph theoretic problem, and expresses constraint ....

Hoover, R. 1992. Alphonse: Incremental computation as a programming abstraction. Sigplan Notices 27, 7 (July), 261--272. ACM SIGPLAN'92 Conference on Programming Language Design and Implementation.

.... in recent years and their many applications [RR93] demonstrated by various incremental algorithms such as [GM79,JG82,RTD83,Yeh83,RP88,Van88,FMB90,AHR 90,RR94] and general incremental computation approaches such as [Ear76,Pai81,PK82,Pai84,HT86, CP89,PT89,FT90,Smi90,Smi91,YS91,SH91,Sun91,Hoo92,van92,Fie93] motivated us to look for the fundamentals of incremental computation and their role in efficient computation. The goal has been a general approach and tools that allow incremental computation to be obtained systematically from non incremental computation and program efficiency to be ....

.... evaluation frameworks [RT88] incremental computation via function caching [PT89] incremental lambda reduction [FT90] formal program manipulation using traditional partial evaluation [SH91,Sun91] the change detailing network of INC [YS91] incremental computation as program abstraction [Hoo92] and incremental term rewriting [van92,Fie93] Such frameworks are called incremental evaluators by Pugh [Pug88b] and general approaches by Field [Fie91] Note that an incremental execution framework always employs a particular incremental algorithm, where the algorithm is designed for executing ....

[Article contains additional citation context not shown here]

Roger Hoover. Alphonse: Incremental computation as a programming abstraction. In Proceedings of the ACM SIGPLAN '92 Conference on PLDI, pages 261--272, California, June 1992.

....results of an existing batch program. Recent research on memoization for functional programs includes improved caching strategies [12] and methods for memoizing specialized functions instead of data values [15] There is also research on adding dependence information to existing imperative code [8]. Incremental execution techniques are general, but suffer in performance due to the need to dynamically process arbitrary input changes. Our restricted application domain, in which the user performs a series of repeated modifications to individual scalar inputs, makes it practical for us to ....

Hoover, Roger. Alphonse: Incremental Computation as a Programming Abstraction. Proceedings of the SIGPLAN `92 Conference on Programming Language Design and Implementation (San Francisco, California, June 1992), 261-272.

....results used in computing the output f(x) also need to be maintained for efficient incremental computation of f(x Phi y) Moreover, certain auxiliary information about x may need to be discovered and maintained as well. Numerous techniques for incremental computation have been developed, e.g. [3, 4, 16, 20, 21, 24, 31, 36, 38, 40, 43, 44, 47, 52]. In [31] we give a systematic transformational approach for deriving an incremental program f 0 from a given program f and an input change Phi. The basic idea is to identify in the computation of f(x Phi y) those subcomputations that are also performed in the computation of f(x) and whose ....

.... function calls [39, 40] saving results of intermediate reductions at appointed places [16] maintaining the change detailing network of INC [52] keeping residual programs for certain input partitions [47] and maintaining intermediate results and dependencies identified by Alphonse annotations [20]. In [30] we have given a cache and prune method to statically transform programs to cache all kinds of intermediate results needed for incremental computation. The basic idea is to (I) extend the program f to a program f that returns all intermediate results, II) incrementalize the program ....

R. Hoover. Alphonse: Incremental computation as a programming abstraction. In Proceedings of the ACM SIGPLAN '92 Conference on PLDI, pages 261--272, California, June 1992.

....under Phi, and for constructing a corresponding program that incrementally maintains these intermediate results. Previous work on this relies on a fixed set of rules [3, 32] applies only to programs with certain properties or schemas [5, 10, 34, 35] or requires program annotations [14, 19, 44]. 2. Our cache and prune method consists of three independent stages, and thus is modular. It has certain nice properties. Stage I gives us maximality by providing all the intermediate results possibly used by Stage II. Stage II uses these intermediate results for the exclusive purpose of ....

.... be needed later, and certain strategies are chosen for using and managing the cache [28] Work in recent years includes [15, 29, 37] Two trends seem obvious: studying specialized cache strategies for classes of problems [38] and adding annotations or certain specifications to subject programs [14, 19, 44]. A drawback of these methods is that they are based on dynamic methods, which are fundamentally interpretive and are hard to be simultaneously both general and powerful. The above drawback can be overcome by transforming subject programs to integrate caching into the transformed programs. In ....

R. Hoover. Alphonse: Incremental computation as a programming abstraction. In Proceedings of the ACM SIGPLAN '92 Conference on PLDI, pages 261--272, California, June 1992.

....incrementally under Phi, and for constructing a corresponding program that incrementally maintains these intermediate results. Previous work on this relies on a fixed set of rules [3, 31] applies only to programs with certain properties or schemas [5, 10, 33, 34] or requires program annotations [14, 19, 44]. 2. Our cache and prune method consists of three independent stages, and thus is modular. It has certain nice properties. Stage I gives us maximality by providing all the intermediate results possibly used by Stage II. Stage II uses these intermediate results for the exclusive purpose of ....

....study of using memoization for incremental evaluation. Examples of the latter include work by Keller and Sleep [19] which proposes annotating applicative languages, work by Sundaresh and Hudak [44, 43] which decides what to cache based on given input partitions of programs, and work by Hoover [14], which proposes annotating an imperative language. The pros and cons of separate caching are well discussed by Bird [5] and Cohen [10] To summarize, the idea is simple, and the subject programs are basically unchanged. But the caching methods are dynamic, and thus are fundamentally interpretive. ....

R. Hoover. Alphonse: Incremental computation as a programming abstraction. In Proceedings of the ACM SIGPLAN '92 Conference on PLDI, pages 261--272, California, June 1992.

....conflict X O(N) propagate N SkyBlue conflict X X X O(M ) Rendezvous mark sweep X O(N) bipartite graph Gangnet matching X X O(N) executed and then executes them in topological order. The execution phase may use any one way constraint satisfaction algorithm, including both eager evaluators [49, 1, 37, 23, 24] and lazy evaluators [49, 25, 2] 8.2 Domain Specific Constraint Solvers Multi way, local propagation solvers may be used either individually or in concert with domainspecific solvers, such as linear constraint solvers [17] non linear constraint solvers [10, 50, 51, 16, 8] and linear equality ....

Roger Hoover. "Alphonse: Incremental Computation as a Programming Abstraction". Sigplan Notices 27, 7 (July 1992), 261-272. ACM SIGPLAN'92 Conference on Programming Language Design and Implementation.

.... of the cache and prune method contrasts with previous work on caching, which either relies on a fixed set of rules [Allen et al. 1981; Paige and Koenig 1982] applies only to programs with certain properties or schemas [Bird 1980; Cohen 1983; Pettorossi 1984; 1987] requires program annotations [Hoover 1992; Keller and Sleep 1986; Sundaresh and Hudak 1991] etc. The dependence analysis for pruning in Stage III uses domain projections to specify specific components of compound values, rather than just heads or tails of list values, and thus complements existing methods for such analyses [Hughes 1990; ....

.... Pugh and Teitelbaum [1989] Examples of the latter include work by Keller and Sleep [1986] which uses annotations for applicative languages, work by Sundaresh and Hudak [Sundaresh 1991; Sundaresh and Hudak 1991] which decides what to cache based on given input partitions of programs, and work by Hoover [1992], which uses annotations for an imperative language. The pros and cons are well discussed by Bird [1980] and Cohen [1983] To summarize, the idea is simple, and the subject programs are basically unchanged. But the caching methods are dynamic and thus fundamentally interpretive. Moreover, the ....

Hoover, R. 1992. Alphonse: Incremental computation as a programming abstraction. In Proceedings of the ACM SIGPLAN '92 Conference on Programming Language Design and Implementation. ACM, New York, 261--272.

.... attribute evaluation frameworks [35] incremental computation via function caching [33] formal program manipulations using traditional partial evaluation [43, 42] incremental lambda reduction [12] the change detailing network of INC [51] incremental computation as a program abstraction [16], etc. In this class, often no explicitly incremental version of an application program is derived and run autonomously by a standard evaluator. Moreover, any input change to an application program is mapped to whatever the framework can handle, which is fixed for each framework. Therefore, these ....

R. Hoover. Alphonse: Incremental computation as a programming abstraction. In Proceedings of the ACM SIGPLAN '92 Conference on PLDI, pages 261--272, California, June 1992.

.... attribute evaluation frameworks [34] incremental computation via function caching [32] formal program manipulations using traditional partial evaluation [42, 41] incremental lambda reduction [12] the change detailing network of INC [50] incremental computation as a program abstraction [16], etc. In this class, often no explicitly incremental version of an application program is derived and run autonomously by a standard evaluator. Moreover, any input change to an application program is mapped to whatever the framework can handle, which is fixed for each framework. Therefore, these ....

R. Hoover. Alphonse: Incremental computation as a programming abstraction. In Proceedings of the ACM SIGPLAN '92 Conference on PLDI, pages 261--272, California, June 1992.

.... problems, general evaluation frameworks are pursued for achieving incremental computation automatically, e.g. incremental computation via function caching[27] formal program manipulations like traditional partial evaluation[41, 40, 10] and incremental computation as a program abstraction[16], etc. Note that, when attribute grammars are used as a general description language for applications, the attribute evaluation framework can be viewed as falling into this class too. The characteristic of work in this class is that a general incremental evaluation model is run for any given ....

R. Hoover. Alphonse: Incremental computation as a programming abstraction. In Proceedings of the ACM SIGPLAN '92 Conference on PLDI, pages 261--272, California, June 1992.

.... is a fundamental issue relevant throughout computer software, e.g. optimizing compilers [1, 2, 15, 20, 60] transformational program development [7, 17, 47, 49, 59] and interactive systems [4, 5, 9, 19, 27, 33, 53, 54] Numerous techniques for incremental computation have been developed, e.g. [2, 3, 22, 28, 29, 30, 41, 48, 51, 52, 55, 58, 61, 64]. Deriving incremental programs. We are engaged in an ambitious effort to derive incremental extended programs automatically (or semi automatically) from nonincremental programs written in standard programming languages. This approach contrasts with many other approaches that aim to evaluate ....

R. Hoover. Alphonse: Incremental computation as a programming abstraction. In Proceedings of the ACM SIGPLAN '92 Conference on PLDI, pages 261--272, California, June 1992.

No context found.

Roger Hoover. "Alphonse: Incremental Computation as a Programming Abstraction". Sigplan Notices 27, 7 (July 1992), 261-272. ACM SIGPLAN'92 Conference on Programming Language Design and Implementation.

No context found.

R. Hoover. Alphonse: incremental computation as a programming abstraction. In Proceedings of the 5th ACM SIGPLAN conference on Programming language design and implementation, pages 261--272. ACM Press, 1992.

No context found.

R. Hoover. Alphonse: incremental computation as a programming abstraction. In Proceedings of the 5th ACM SIGPLAN conference on Programming language design and implementation, pages 261--272. ACM Press, 1992.

No context found.

R. Hoover. Alphonse: incremental computation as a programming abstraction. In Proceedings of the 5th ACM SIGPLAN conference on Programming language design and implementation, pages 261--272. ACM Press, 1992.

No context found.

R. Hoover. Alphonse: incremental computation as a programming abstraction. In Proceedings of the 5th ACM SIGPLAN conference on Programming language design and implementation, pages 261--272. ACM Press, 1992.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC