J. Heering, P. Klint, and J. Rekers. Incremental generation of lexical scanners. ACM Transactions on Programming Languages and Systems (TOPLAS), 14(4):490--520, 1992.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....syntax of this language and optionally other operations on programs in the language such as, for instance, interpretation, compilation or transformation) and generates corresponding tools as output. From the syntax definition of a language in SDF various components are generated: a lexical scanner [23], a Generalized LR parser [22] a syntax directed editor [28] a pretty printer [12] and optionally traversal functions and program analysis functions [8] For the operations defined on programs, efficient term rewrite engines are generated. We mention that Generalized LR parsing is particularly ....

J. Heering, P. Klint, and J. Rekers. Incremental generation of lexical scanners. ACM Transactions on Programming Languages and Systems, 14(4):490--520, 1992.

....a COBOL grammar for reengineering purposes. As an example we implemented an OS VS COBOL grammar using the Asf Sdf Meta Environment that contains Rekers [34] implementation of incremental Generalized LR parsing. The Asf Sdf Meta Environment also contains incremental generation of lexical scanners [23]. Those features made this system for us a perfect candidate to prototype our ideas on parsing for reengineering. We think that successfully defining a COBOL grammar plus some dialects and extensions using GLR parsing technology gives clear evidence that this technology scales up to real world ....

J. Heering, P. Klint, and J. Rekers. Incremental generation of lexical scanners. ACM Transactions on Programming Languages and Systems, 14(4):490--520, 1992.

....does not lead to a regeneration from scratch of the parsers involved. Instead, they are informed about the change and updated accordingly. In other words, parser generation proceeds incrementally. Not only parsers, but also lexical analyzers and term rewriting systems are updated incrementally [Hen91, HKR90, HKR92, HKR94]. A last important feature of Asf Sdf is the support for literate specifications [Vis93] in the sense of the literate programming approach advocated by Knuth [Knu92] For instance, the text as entered by the specifier for modules Lambda Syntax and Variables is visible in the windows of Figure ....

....algorithm is discussed in class, the specification of this algorithm can be found in the course notes. Extend this specification in such a way that scanners can be generated in an incremental manner. The incremental scanner generation algorithm can be found in the course notes as well, or in [HKR94]. The last set of exercises were used for getting acquainted with parsing techniques and parser generation. 4.6 Conclusions The modular structure of ASF SDF specifications makes it possible to explain the various concepts of scanners, and parsers in a refinement wise manner. Furthermore, the ....

J. Heering, P. Klint, and J. Rekers. Lazy and incremental program generation. ACM Transactions on Programming Languages and Systems, 16(3), May 1994.

....does not lead to a regeneration from scratch of the parsers involved. Instead, they are informed about the change and updated accordingly. In other words, parser generation proceeds incrementally. Not only parsers, but also lexical analyzers and term rewriting systems are updated incrementally [Hen91, HKR90, HKR92, HKR94]. A last important feature of Asf Sdf is the support for literate specifications [Vis93] in the sense of the literate programming approach advocated by Knuth [Knu92] For instance, the text as entered by the specifier for modules Lambda Syntax and Variables is visible in the windows of Figure ....

J. Heering, P. Klint, and J. Rekers. Incremental generation of lexical scanners. ACM Transactions on Programming Languages and Systems, 14(4):490-- 520, 1992.

....the description of the main algorithms needed in the incremental processing of specifications 8 written in formalisms using textual modularization. The ASF SDF system is a particular application of the general architecture described here. The syntax definition formalism SDF reference manual [HHKR92] SDF is a formalism for the definition of syntax which is comparable to BNF in some respects, but has a wider scope in that it also covers the definition of lexical and abstract syntax. Its design and implementation are tailored towards the language designer who wants to develop new languages as ....

....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. Incremental generation of lexical scanners [HKR92] 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 amortized over many uses of the ....

J. Heering, P. Klint, and J. Rekers. Incremental generation of lexical scanners. ACM Transactions on Programming Languages and Systems, 14(4):490-- 520, 1992.

....language, there is a wide range of choices for the granularity of steps. An execution step can be a construct from a high level language at one extreme or a machine instruction at the other extreme. Each step is described by an event. The use of events in monitoring process behavior is common [2, 6, 7, 13, 15, 16, 19, 23]. Usually events provide only that subset of process behavior which is important for a particular application. For example, Hanson [6] provides the following events: variable referencing, statement execution, program interruption, function call and return, and execution time errors. Events have ....

J. Heering and P. Klint. Towards monolingual programming environments. ACM Transactions on Programming Languages and Systems, 7(2):183--213, April 1985.

....much development effort can be wasted if improved approaches are not publicised. Considerable progress has been made towards the goal of automatically generating programming language compilers. Using specialised notations it is possibleto specify compilation sub tasks such as lexical analysis [22, 17, 9, 16, 1], parsing [18, 23, 2, 8] and semantic analysis [24, 3, 21, 27] Other compiler tasks such as code generation for complex architectures have partially yielded to attack and are the subject of continuing research [4, 6] Libraries of existing infrastructure can be used to combine solutions for ....

HEERING, J., KLINT, P., AND REKERS, J. Incremental generation of lexical scanners. ACM Transactions on Programming Languages and Systems 14, 4 (Oct. 1992), 490--520.

....interpreted approaches. Keywords: Boolean differential, Boolean evaluation, Boolean expressions, Unison algorithm. 1 Introduction Efficient evaluation of Boolean expressions is an important part of many software systems. Some applications include: data base search [11] programming environments [6], modeling of digital circuits and software systems [2] debugging [9] event recording [11] search and optimization [5] Interpretive evaluation of Boolean expressions is expensive in execution time. Improvements include compiled evaluation [2] special purpose circuits [3, 11] and reductions ....

J. Heering and P. Klint. Towards monolingual programming environments. ACM Transactions on Programming Languages and Systems, 7(2):183--213, April 1985.

....and fast backtracking. 1 Introduction Reverse execution provides access to old states of an executing process. It is a well established concept in computer science used in program development and debugging [2, 6, 20, 21, 27, 28, 30] in programming environments and human computer interaction [1, 10, 16, 18, 29], in fault tolerant computing [5, 7, 14, 15] and in speculative computation [9, 13] In computer architecture, techniques of reverse execution are used to provide precise interrupts [12, 23] Implementations of reverse execution fall into roughly two classes: hardware and software ap Appeared in ....

....support for reverse execution enables many useful applications that go beyond the simple use of reverse execution in debugging. Some of these applications are described in this section. 3. 1 A Generic Undo Operation A generic undo operation is an important construct in programming environments [1, 10, 16]. A computer with the support for reverse execution can return any program to a state in the past regardless of the programming language or the programming environment. A specific case of the usefulness of reverse execution may be found in interaction with complex scientific applications. These ....

J. Heering and P. Klint. Towards monolingual programming environments. ACM Transactions on Programming Languages and Systems, 7(2):183-- 213, April 1985.

....made them attractive, but a satisfactory way to incorporate garbage collection and a sophisticated run time environment in introspective systems was not found. Therefore, the decision was made to use C. Each step is described by an event. The use of events in monitoring process behavior is common [15, 64, 66, 111, 120, 121, 150, 168]. Usually events provide only that subset of process behavior which is important for a particular application. For example, Hanson [64] provides the following events: variable referencing, statement execution, program interruption, function call and return, and execution time errors. Events have ....

....Information in the execution stream includes the history of a process. This section discusses two applications of the history. 3.4. 1 Reverse Execution in Human Computer Interaction A generic undo operation is an important construct in human computer interaction and programming environments [11, 66, 99]. Because it supports reverse execution, an introspective computer can return any program to a state in the past regardless of the programming language or the programming environment. A common application of reverse execution is debugging [15, 50, 121, 182] When a program exhibits incorrect ....

[Article contains additional citation context not shown here]

J. Heering and P. Klint. Towards monolingual programming environments. ACM Transactions on Programming Languages and Systems, 7(2):183--213, April 1985.

....regeneration from scratch of the parsers involved. Instead, they are informed about the change and updated accordingly. In other words, parser generation proceeds incrementally. Not only parsers, but also lexical analyzers and term rewriting systems are updated incrementally [Hen91, HKR90, HKR92, HKR94] A last important feature of Asf Sdf is the support for literate specifications [Vis93] in the sense of the literate programming approach advocated by Knuth [Knu92] For instance, the text as entered by the specifier for modules Lambda Syntax and Variables is visible in the windows of Figure 3. ....

J. Heering, P. Klint, and J. Rekers. Lazy and incremental program generation. ACM Transactions on Programming Languages and Systems, 16(3), May 1994.

....to a regeneration from scratch of the parsers involved. Instead, they are informed about the change and updated accordingly. In other words, parser generation proceeds incrementally. Not only parsers, but also lexical analyzers and term rewriting systems are updated incrementally [Hen91, HKR90, HKR92, HKR94] A last important feature of Asf Sdf is the support for literate specifications [Vis93] in the sense of the literate programming approach advocated by Knuth [Knu92] For instance, the text as entered by the specifier for modules Lambda Syntax and Variables is visible in the windows of ....

J. Heering, P. Klint, and J. Rekers. Incremental generation of lexical scanners. ACM Transactions on Programming Languages and Systems, 14(4):490--520, 1992.

....representations via compilation and interpretation and its support for optimistic transmission are unique. Lazy compilation for transmitted agents is another unique feature. However, the general technique of lazy program generation has been investigated in other contexts. Heering et al. [14] developed a syntax oriented editor where the user is permitted to 13 change the syntax interactively. Changes to the syntax require the generation of new parsers, but this operation takes too long for interactive performance. Parsers are therefore generated lazily; when part of the parser is ....

J. Heering, P. Klint, and J. Rekers. Lazy and incremental program generation. ACM Transactions on Programming Languages and Systems, 16(3):1010--1023, May 1994.

....operator is to shift the boxes horizontally over is spaces. The term #V [ begin #I [ declarations ] #I is=4 [ statements ] end ] is prettyprinted as: begin declarations statements end The default value of this option is 2. The context free syntax of the box language is defined in SDF [HK89, HHKR92] context free syntax #H OPERATOR #V OPERATOR #HV OPERATOR #HOV OPERATOR #I OPERATOR hs OPTION SYMBOL vs OPTION SYMBOL is OPTION SYMBOL OPTION SYMBOL = NAT OPTION STRING BOX OPERATOR OPTION [ BOX ] BOX BOX BOX LIST The non terminal ....

....rewrite rules for restoring them. The prettyprinter generator described in this paper is used within the ASF SDF Metaenvironment [Kli93] which is a programming environment generator using incremental program generation techniques [HKR91] Some of the tools generated, such as the lexical scanner [HKR92] and parser [HKR89] are based on this technique. The incremental generation of prettyprinters is still a research issue. We have used the generator for deriving prettyprinters for several languages for which an ASF SDF specification exists, such as PASCAL, CLaX [DT92] the box language itself, ....

J. Heering, P. Klint, and J. Rekers. Incremental generation of lexical scanners. ACM Transactions on Programming Languages and Systems, 14(4):490--520, 1992.

....usually require that a program must be generated in its entirety before it can be used. If generation time is scarce, it may be better to generate only those parts that are indispensable for processing some particular data. A related application is lazy generation of scanners and parsers [HKr89, HKR92, Kos90] A lazy scanner postpones the construction of parts of an automaton for recognizing certain textual patterns until the parts are needed. Similarly, a lazy parser generates a parse table during parsing, but only those parts that are needed to parse the input sentence at hand. User ....

J. Heering, P. Klint, and J. Rekers. Incremental generation of lexical scanners. ACM Transactions on Programming Languages and Systems, 14(4):490 -- 520, October 1992.

....in real time, but usually they are not a standard part of computer equipment and are not integrated into programming environments. Therefore, general programming tools cannot rely on the availability of hardware monitors. Software approaches to monitoring include event generation and processing [1, 3, 6, 8, 12, 13, 14, 17, 18]. An executor, written in a high level language, produces events that are related to concepts in that high level language. Examples of such events include function calls or changes in variable values. Events are processed by event handlers included in the program itself [10] by a postprocessing ....

J. Heering and P. Klint. Towards monolingual programming environments. ACM Transactions on Programming Languages and Systems, 7(2):183-- 213, April 1985.

....and term rewriting. They led the design and implementation of the ASF SDF Language Prototyping System [15] which generates programming environments from algebraic, rewrite rule based, language definitions. By using generation schemes that are both lazy (just in time) and incremental [7, 8, 9], the system supports incremental development of parsers, typecheckers, translators, program transformers, and other language processors. Earlier work on transformation strategies done in the context of ASF SDF is reported in [10] Both the C preprocessor for SOPHUS style programs and the Cobol ....

....and other language processors. Earlier work on transformation strategies done in the context of ASF SDF is reported in [10] Both the C preprocessor for SOPHUS style programs and the Cobol transformation tool mentioned above were developed using the ASF SDF system. 1. 7 Publications [5, 4, 15, 7, 8, 9] are publications of the applicants themselves relevant to the current proposal. ....

J. Heering, P. Klint, and J. Rekers. Lazy and incremental program generation. ACM Transactions on Programming Languages and Systems, 16:1010-- 1023, 1994.

....and term rewriting. They led the design and implementation of the ASF SDF Language Prototyping System [15] which generates programming environments from algebraic, rewrite rule based, language definitions. By using generation schemes that are both lazy (just in time) and incremental [7, 8, 9], the system supports incremental development of parsers, typecheckers, translators, program transformers, and other language processors. Earlier work on transformation strategies done in the context of ASF SDF is reported in [10] Both the C preprocessor for SOPHUS style programs and the Cobol ....

....and other language processors. Earlier work on transformation strategies done in the context of ASF SDF is reported in [10] Both the C preprocessor for SOPHUS style programs and the Cobol transformation tool mentioned above were developed using the ASF SDF system. 1. 7 Publications [5, 4, 15, 7, 8, 9] are publications of the applicants themselves relevant to the current proposal. ....

J. Heering, P. Klint, and J. Rekers. Incremental generation of lexical scanners. ACM Transactions on Programming Languages and Systems, 14:490-- 520, 1992.

....of the generator and incrementality of the generated environment. One of the hall marks of the current implementation of the Asf Sdf system is the use of lazy incremental techniques for the generation of lexical scanners, parsers, and, to a lesser extent, term rewriting systems [HKR90, HKR92] This approach is guided by the following principles: P. Klint ffl lazy : only generate those parts of an implementation that are currently needed. ffl incremental : whenever the input description changes (e.g. the grammar used by the parser generator to generate a parser) remove those ....

J. Heering, P. Klint, and J. Rekers. Incremental generation of lexical scanners. ACM Transactions on Programming Languages and Systems, 14(4):490--520, 1992.

....run time type checking, garbage collection, run time generation of programs, and the like. INRIA s Mentor system had been implemented in Pascal and the lack of garbage collection and the limitations of Pascal s type system were felt as serious drawbacks. CWI s work on monolingual environments [HK85] was based on an earlier, positive, experience with the Summer programming language [Kli80] that supported dynamic typechecking and automatic garbage collection. Our collective experiences were thus consistent with each other. INRIA s research group for VLSI design had just completed a small, ....

J. Heering and P. Klint. Towards monolingual programming environments. ACM Transactions on Programming Languages and Systems, 7(2):183--213, 1985.

....to write first order terms as well as equations in arbitrary concrete syntactic forms: from a given Sdf definition for some context free grammar, a fixed mapping from strings to terms can be derived. Sdf specifications can be executed using general scanner and parser generation techniques [HKR90, HKR92]. An Asf Sdf specification consists of a sequence of named modules. Each module may contain: Imports of other modules. Sort declarations defining the sorts of a signature. Lexical syntax defining layout conventions and lexical tokens. Context free syntax defining the concrete syntactic forms ....

J. Heering, P. Klint, and J. Rekers. Incremental generation of lexical scanners. ACM Transactions on Programming Languages and Systems, 14(4):490--520, 1992.

No context found.

J. Heering, P. Klint, and J. Rekers. Incremental generation of lexical scanners. ACM Transactions on Programming Languages and Systems (TOPLAS), 14(4):490--520, 1992.

No context found.

J. Heering and P. Kint. Towards Monolingual Programming Environments. ACM Transactions on Programming Languages and Systems, April 1985.

No context found.

J. Heering, P. Klint, and J. Rekers. Incremental generation of lexical scanners. ACM Transactions on Programming Languages and Systems (TOPLAS), 14(4):490--520, 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