J. Heering
Abstract
Current program generators usually operate in a greedy manner in the sense that a program must be generated in its entirety before it can be used. If generation time is scarce, or if the input to the generator is subject to modification, it may be better to be more cautious and to generate only those parts of the program that are indispensable for processing the particular data at hand. We call this lazy program generation. Another, closely related strategy is incremental program generation. When its input is modified, an incremental generator will try to make a corresponding modification in its output rather than generate a completely new program. It may be advantageous to use a combination of both strategies in program generators that have to operate in a highly dynamic and/or interactive environment.
- ~AHO, A. V., SETHI, R., nN~) ULLMAN, J.D. 1986. Compilers--Princtples, Techniques, and Tools. ~Addison-Wesley, Reading, Mass.]] Google Scholar
- ~BROWN, P.j. 1976. Throw-away compiling. Softw. Pract. Exp. 6, 3, 423-434.]]Google Scholar
- ~CLEAVELAND, J.C. 1988. Building application generators. IEEE Softw. 5, 7 (July), 25-33.]] Google Scholar
- ~FRITZ$ON, P. 1982. Fine-grained incremental compilation for Pascal-like languages. Rep. ~LiTH-MAT-R-82-15, Software Systems Research Center, Link5ping Univ.]]Google Scholar
- ~FRITZSON, P. 1983. Symbolic debugging through incremental compilation in an integrated ~environment. J. Syst. Softw. 3, 4, 285-294.]]Google Scholar
- ~HEERING, J.. HENDRIKS, P. R. H., KLINT, P., AND REKERS, J. 1989. The syntax definition ~formalism SDF--Reference Manual. SIGPLAN Not. 24, 11 (Nov.), 43-75.]] Google Scholar
- ~HEERING, J., KLINT, P., AND REKERS, J. 1990. incremental generation of parsers. IEEE Trans. ~Softw. Eng. SE-16, 12 (Dec.), 1344-1351.]] Google Scholar
- ~HEERING, J., KLINT, P., AND REKERS, J. 1992. Incremental generation of lexical scanners. ACM ~Trans. Program. Lang. Syst. 14, 4 (Oct.), 490-520.]] Google Scholar
- ~HOFFMANN, C. M., AND O'DONNELL, M.J. 1982. Pattern matching in trees. J. ACM 29, 1, ~68-95.]] Google Scholar
- ~HOPPER, G. M. 1981. Keynote address to the ACM History of Programming Languages ~Conference. In History of Programming Languages. Academic Press, New York, 7-20.]] Google Scholar
- ~HORSPOOL, R.N. 1990. Incremental generation of LR parsers. Comput. Lang. 15, 205-223.]] Google Scholar
- ~HORSPOOL, R.N. 1989. ILALR: An incremental generator of LALR(1) parsers. In Compiler ~Compilers and High Speed Compilation. Lecture Notes in Computer Science, vol. 371. ~Springer-Verlag, New York, 128-136.]] Google Scholar
- JOHNSON, S.C. 1975. Yacc--Yet another compiler-compiler. Computing Science Tech. Rep. No. ~32, Bell Laboratories, Murray Hill, N.J.]]Google Scholar
- KLINT, P. 1991. Lazy scanner generation for modular regular grammars. Rep. CS-R9158, ~Dept. of Software Technology, CWI, Amsterdam.]]Google Scholar
- KOSKIMIES, K. 1990. Lazy recursive descent parsing for modular language implementation. ~Softw. Prac. Exp. 20, 8, 749-772.]] Google Scholar
- PAXSON, V. 1989. FLEX. Lexical scanner generator developed at Lawrence Berkeley Labora- ~tory, Berkeley, Calif.]]Google Scholar
- REKERS, J. 1992. Parser generation for interactive environments. Ph.D. thesis, Programming ~Research Group, Univ. of Amsterdam.]]Google Scholar
- SESTOFT, P., AND ZAMULIN, A. V. 1988. Annotated bibliography on partial evaluation and ~mixed computation. New Gen. Comput. 6, 5, 309-354.]] Google Scholar
- SZAFRON, D., AND NG, R. 1990. LexAGen: An interactive incremental scanner generator. Soflw. ~Prac. Exp. 20, 5, 459-483.]] Google Scholar
- TOMITA, M. 1985. Efficient Par~ing for Natural Languages. Kluwer, Boston, Ma~.]] Google Scholar
- WALTERS, H.R. 1991. On equal terms: Implementing algebraic specifications. Ph.D. thesis, ~Programming Research Group, Univ. of Amsterdam, Chapter 3.]]Google Scholar
- YELLIN, D. M., AND STRON, R.E. 1991. INC: A language for incremental computations. ACM ~Trans. Program. Lang. Syst. 13, 2, 211-236.]] Google Scholar
Index Terms
- Lazy and incremental program generation
Recommendations
Incremental generation of lexical scanners
It is common practice to specify textual patterns by means of a set of regular expressions and to transform this set into a finite automaton to be used for the scanning of input strings. In many applications, the cost of this preprocessing phase can be ...
Practical typed lazy contracts
ICFP '12Until now there has been no support for specifying and enforcing contracts within a lazy functional program. That is a shame, because contracts consist of pre- and post-conditions for functions that go beyond the standard static types. This paper ...
Practical typed lazy contracts
ICFP '12: Proceedings of the 17th ACM SIGPLAN international conference on Functional programmingUntil now there has been no support for specifying and enforcing contracts within a lazy functional program. That is a shame, because contracts consist of pre- and post-conditions for functions that go beyond the standard static types. This paper ...
Reviews
Gregory M. Aharonian
In the era of multimillion-line systems and programs with hundreds of thousands of lines of code, despite having 100+ megahertz microprocessors for development, in some cases the problem of lengthy compilation or source code generation time arises. While some languages, such as Ada, provide packaging of source code, allowing compilation of only those packages that have been changed (and any dependencies easily determinable), there may be cases where substantial parts of the program have to be regenerated or, as the authors point out, where the program is too large to be run in its entirety. In such cases, the authors propose lazy and incremental program generation. Lazy program generation generates only those parts of a program that are needed to process the current data set. Incremental program generation modifies an existing system (such as object code) based on changes in the source version. Under some conditions, combining the two techniques might have an advantage. The paper first explores algorithms for each of the two techniques, and then proposes an algorithm combining the two. Results from hand-implementing the authors' algorithm on a lexical scanner and parser generator are then discussed. Mixed results were obtained. While I found the paper interesting, the authors' conclusions may limit its relevance. To be useful, “most expansion steps should be relatively small so that the total generation time can be distributed more or less evenly over many computations.” Small expansions might imply the type of occasional modification for which greedy generation would not have a big impact on the work schedule, however. To be practical, “lazy/incremental program generation requires an efficient way of establishing which part of the already generated program remains valid in a modified context,” an analysis that may be as computationally lengthy as the greedy generation style the authors are trying to improve upon.
Access critical reviews of Computing literature here
Become a reviewer for Computing Reviews.
Comments