8 citations found. Retrieving documents...
R. Nigel Horspool and Michael R. Levy. Mkscan --- an interactive scanner generator. Software---Practice and Experience, 17(6):369-- 378, June 1987.

 Home/Search   Document Not in Database   Summary   Related Articles   Check  

This paper is cited in the following contexts:
An Implementation of the Haskell Language - Spinellis (1990)   (Correct)

....The solution finally adopted was a hybrid 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 ....

R. Nigel Horspool and Michael R. Levy. Mkscan --- an interactive scanner generator. Software---Practice and Experience, 17(6):369-- 378, June 1987.


A Model and Toolset for the Uniform Tagging of Encoded Documents - Barnes, MAMRAK (1991)   (1 citation)  (Correct)

....a translation rule for identifier would be: A Za z] A Za z0 9] mkidn] where mkidn is a library routine that performs the appropriate processing for an identifier. Lexical analyzer generators that have been designed specifically for programming languages are # GLA [28] Alex [29] Mkscan [30], and LexAGen [31] These specialized lexical analyzer generators for programming languages will not meet our requirements for digital libraries. They are limited to understanding the set of token classes in the programming language domain. The domain of electronic documents has a different set ....

R. Nigel Horspool and Michael R. Levy, `Mkscan -- an interactive scanner generator', Software Practice and Experience, 17(6), 369--379, (June 1987).


A Language Independent Scanner Generator - Teodor Rus And (1998)   (Correct)

....and Rex [4] treated these non regular constructs as exceptions to be handled outside of the syntax of the lexicon specification language, usually by requiring the user to write code in a standard programming language. Other lexical analyzer generators, such as Alex [11] GLA [15] and Mkscan [6], have made a move toward incorporating the non regular features into the syntax of the lexicon specification. Still others, have moved the entire lexical analysis process into the parser, thus specifying them with the same BNF rules as used for the rest of the language syntax [14] Such ....

....are no other transitions from state 2 so the stack is left empty. At line 11 the algorithm finds T 3 .cond to be the CT index I p3 . EvalCond(CT[I p3 , ulex 2 ) true, as seen in Example 9. Thus, a transition to to state 6 on ulex 3 in the UniBuf can be made. At line 13 the algorithm finds TT[6][ffl] fT 5 g and TT[6] N] NULL. Thus, it pushes (6, T 5 , ulex 3 ) on the stack. and returns to the loop. ffl In the fourth iteration of the while loop, at line 7 the top item stack is popped out, giving state = 6, tran=T 5 , and ulex=ulex 3 . There are no other transitions from state 6, so ....

[Article contains additional citation context not shown here]

R.N. Horspool and M.R. Levy. Mkscan -- an interactive scanner generator. Software -- Practice and Experience, 17(6):369--378, 1987.


A Language Independent Scanner Generator - Teodor Rus And (1998)   (Correct)

....and Rex [4] treated these non regular constructs as exceptions to be handled outside of the syntax of the lexicon specification language, usually by requiring the user to write code in a standard programming language. Other lexical analyzer generators, such as Alex [11] GLA [15] and Mkscan [6], have made a move toward incorporating the non regular features into the syntax of the lexicon specification. Still others, have moved the entire lexical analysis process into the parser, thus specifying them with the same BNF rules as used for the rest of the language syntax [14] Such ....

....from state 2 so the stack is left empty. At line 12 the algorithm finds cond = I p3 and evaluates the property CT [I p3 ] of ulex 2 which is found to be true, since in Example 9, EvalCond(CT [I p3 ] ulex 2 ) true. A transition is made to state 6 and input is advanced to ulex 3 in the UniBuf . TT[6][N] NULL so there are no transitions from state 6 for inputs with class specifier N. However TT[2] ffl] fT 5 g, so there is list of epsilon transitions, the first of which is T 5 . 6, T 5 , ulex 3 ) is pushed onto the stack. The algorithm now returns to the top of the loop. ffl In the ....

R.N. Horspool and M.R. Levy. Mkscan -- an interactive scanner generator. Software -- Practice and Experience, 17(6):369--378, 1987.


On the Look-Ahead Problem in Lexical Analysis - Wuu Yang (1995)   (Correct)

....in the same way. Let s consider state 9. The suffix of this state is ac . The SFA cannot scan ac completely. Thus, b = a and a = c . The SFA ends in state 2 when b is used as input. Since state 2 is an accepting state, the token associated with state 2 (written as T2) is appended to output [9]. Since the SFA cannot scan a, continuation [9] is marked as error. # There are several ways to reduce the sizes of the three tables. First, all entries of the accepting states in the three tables are not necessary. Second, all entries of the non accepting states that are not reachable from ....

....The suffix of this state is ac . The SFA cannot scan ac completely. Thus, b = a and a = c . The SFA ends in state 2 when b is used as input. Since state 2 is an accepting state, the token associated with state 2 (written as T2) is appended to output [9] Since the SFA cannot scan a, continuation [9] is marked as error. # There are several ways to reduce the sizes of the three tables. First, all entries of the accepting states in the three tables are not necessary. Second, all entries of the non accepting states that are not reachable from accepting states will not be needed by the scanner. ....

[Article contains additional citation context not shown here]

Horspool, R.N. and Levy, M.R., Mkscan---An interactive scanner generator, Software---Practice and Experience 17(6) pp. 369-378 (June 1987).


Mealy Machines Are A Better Model Of Lexical Analyzers - Yang (1996)   (Correct)

....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 discussed in [18] ....

R.N. Horspool and M.R. Levy, Mkscan---An interactive scanner generator, Software---Practice and Experience 17(6) pp. 369-378 (June 1987). - 21 -


MultiLex, A Pipelined Lexical Analyzer - Timothy Bickmore Robert   (Correct)

No context found.

R. N. Horspool and M. R. Levy, "Mkscan---An interactive scanner generator," Software Practice and Experience, 17, 369--378, 1987.


LexAGen: An Interactive Incremental Scanner Generator - Duane Szafron (1990)   (3 citations)  (Correct)

No context found.

R. N. Horspool and M.R. Levy, "Mkscan - An Interactive Scanner Generator," Software - Practice & Experience, 17(6), 369-378 (1987).

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