V. P. Heuring. The automatic generation of fast lexical analysers. Software---Practice and Experience, 16(9):801--808, September 1986.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....of 2 and 3; a hand crafted analyser in C using a special input library. The advantages of using language development tools are presented in [JL87] A number of tools which automate the task of creating lexical analysers such as 1 lex [Les75] mkscan [HL87] flex [Pax89] and the one described in [Heu86] are available. One of the tools described, the lexical analyser generator lex [Les75] was initially used. Lex is not widely adopted. In [AKW79, section 5] the authors indicate that they are using lex, but other implementation descriptions such as [Joh82, p. 6] outline hand crafted analysers. ....

....6] outline hand crafted analysers. This trend was verified by examination of the source code of publicly available language systems such as the GNU C compiler [Sta89] and PERL [Wal88] The reason for this appears to be that analysers generated by lex are slow and consume a lot of space. In fact, Heu86] suggests that nearly all lexical analysers for production compilers are written by hand. A formal design methodology for writing scanners is discussed in [DGM80] A practical design outline for a hand crafted parser that is roughly the base for my design is found in [Wai86] The major ....

[Article contains additional citation context not shown here]

V. P. Heuring. The automatic generation of fast lexical analysers. Software---Practice and Experience, 16(9):801--808, September 1986.

....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 ....

....for hand coding compilers are often not widely publicised and may be reinvented by many developers. Previous work evaluating the performance of generated compilers has largely concentrated on subtasks of the compilation problem. Lexical analyser generators have been compared with each other [17, 9, 1] and with the minimal lexical analyser: a program that examines each input character once without any further processing[10] Similarly, the performance of parser generators has been examined (e.g. see [29, 14] Tofte reports timing results from a comparison of two generated code generators ....

HEURING, V. P. The automatic generation of fast lexical analysers. Software --- Practice and Experience 16, 9 (Sept. 1986), 801--808.

....continuation, action, and output tables, the new scanner discussed in this paper may solve the right context problem without re scanning. Nawrocki [15] solves a problem similar to that of Alex and LexAGen by checking the left context derived from the LALR grammars of the programming languages. GLA [8] does not address the lookahead problem; backtracking is not allowed. Rex [7] uses a tunnel automaton for efficient scanner generation. It does not address the look ahead problem. Traditionally, scanners generated from regular expressions [10] are slower than one carefully coded by hand. However, ....

....scanner generation. It does not address the look ahead problem. Traditionally, scanners generated from regular expressions [10] are slower than one carefully coded by hand. However, Waite [18] reports that new scanner generators can produce scanners that are as fast as hand coded scanners. GLA [8] and Mkscan [9] do not support the full set of regular expressions. They aim at handling only those tokens that are used in common programming languages. LexAGen [17] provides a graphic user interface for constructing scanners incrementally. ALADIN [5] ignores the lookahead problem by adopting a ....

Heuring, V.P., The automatic generation of fast lexical analysers, Software---Practice and Experience 16(9) pp. 801-808 (September 1986).

....generation 1. INTRODUCTION Considerable progress has been made toward the goal of automatically generating programming language compilers. Using specialized notations it is possible to specify compilation subtasks such as lexical analysis [Bumbulis and Cowan 1993; Gray 1988; Heering et al. 1992; Heuring 1986; Lesk 1975] parsing [Dencker et al. 1984; Gray 1987; Johnson 1975; Rohrich 1980] and semantic analysis [Deransart et al. 1988; Lee 1989; Schmidt 1986; Tofte 1990] Other compiler tasks such as code generation for complex architectures have partially yielded to attack and are the subject of ....

....Anthony M. Sloane licised and may be reinvented by many developers. Previous work evaluating the performance of generated compilers has largely concentrated on subtasks of the compilation problem. Lexical analyzer generators have been compared with each other [Bumbulis and Cowan 1993; Gray 1988; Heuring 1986] and with the minimal lexical analyzer: a program that examines each input character once without any further processing [Gray 1989] Similarly, the performance of parser generators has been examined (e.g. see Waite and Carter [1985] and Grosch [1990] Tofte [1990] reports timing results from ....

Heuring, V. P. 1986. The automatic generation of fast lexical analysers. Softw. Pract. Exper. 16, 9 (Sept.), 801--808.

....sense. LexAGen [13] which is similar to Alex, allows two character look ahead and employs special LookAheadStates to solve the problem. Nawrocki [14] solves a problem similar to that of Alex and LexAGen by checking the left context derived from the LALR grammars of the programming languages. GLA [15] does not address the look ahead problem; backtracking is not allowed. Rex [16] which uses a tunnel automaton for efficient scanner generation, does not address the look ahead problem. GLA [15] and Mkscan [17] do not support the full set of regular expressions. They aim at handling only those ....

....and LexAGen by checking the left context derived from the LALR grammars of the programming languages. GLA [15] does not address the look ahead problem; backtracking is not allowed. Rex [16] which uses a tunnel automaton for efficient scanner generation, does not address the look ahead problem. GLA [15] and Mkscan [17] do not support the full set of regular expressions. They aim at handling only those tokens that are used in common programming languages. LexAGen [13] provides a graphic user interface for constructing scanners incrementally. Incremental generation of lexical analyzers is also ....

V.P. Heuring, The automatic generation of fast lexical analysers, Software---Practice and Experience 16(9) pp. 801-808 (September 1986).

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