|[3 earlier articles]|
|Re: Compiler Construction in Ada email@example.com (1993-01-07)|
|Re: Compiler Construction in Ada firstname.lastname@example.org (1993-01-08)|
|Re: Compiler Construction in Ada email@example.com (1993-01-08)|
|Re: Compiler Construction in Ada firstname.lastname@example.org (1993-01-08)|
|Re: Compiler Construction in Ada email@example.com (1993-01-10)|
|Re: Compiler Construction in Ada firstname.lastname@example.org (1993-01-11)|
|Re: Compiler Construction in Ada email@example.com (1993-01-12)|
|Re: Compiler Construction in Ada firstname.lastname@example.org (1993-01-13)|
|Re: Compiler Construction in Ada email@example.com.Virginia.EDU (1993-01-15)|
|Re: Compiler Construction in Ada firstname.lastname@example.org (1993-01-15)|
|Re: Compiler Construction in Ada email@example.com (1993-01-15)|
|Re: Compiler Construction in Ada firstname.lastname@example.org (Andrew Dunstan) (1993-01-17)|
|From:||email@example.com (Jonathan Eifrig)|
|Organization:||The Johns Hopkins University CS Department|
|Date:||Tue, 12 Jan 1993 00:12:03 GMT|
|Keywords:||courses, Ada, books|
firstname.lastname@example.org (Brent Burton) writes:
>This format [hand-coded lexer/parser in Pascal, using the Dragon book]
>proved to be quite effective and educational. Through
>previous work at IBM, I had experience with lex and yacc already and a
>good understanding of the parsing process. However, the hand-coding
>approach was, I feel, mandatory to learn the important underlying
>algorithms and to better understand the roles lex and yacc play. After
>the the discussion about LL and LALR parsers, I could finally understand
>the shift/reduce and reduce/reduce errors. ;-)
Having been involved in teaching the compiler design course here
at Hopkins for the last two years, I thought I'd put my two cents in.
(For the record, the first two years used the Dragon book, with a bunch of
hand-written supplements, while the last year used Fischer/LeBlanc (C
Basically, I'd agree with Brent's motives: it's very important to
understand the theory of shift/reduce parsing and backing-up DFA lexing
before one can use the lex/yacc family of tools effectively. However, I
don't think that necessarily means writing lexers/parsers by hand.
Here at Hopkins we structure the course around the semester
project, which traditionally has been writing a Toy-to-C translator, where
Toy is a Pascal-like language with integer and function types, ref and
array constructors, and first-class functions. (Function closures are
what make the translation non-trivial). The first half of the
semester-long course's lectures are all on parsing theory, using Gough's
excellent "Syntax Analysis and Software Tools" as a supplemental text.
However, the students build their lexers and parsers using C, lex, and
yacc. I really don't see that subjecting students to the torture of
cranking out lexers for a grammar with something like thirty keywords
accomplishes much other than convincing them one is a sadist. Don't even
think about LR parsers with non-trivial action functions; debugging even
the machine- generated ones is a horror show.
I think that it's much better to get the student's up and running
with a useable parser in a short amount of time. This lets them
concentrate on the more interesting parts of the compiler, like the
type-checker, and experiment with different run-time strategies. Yes, the
theory of LR parsing is very important to learn, but I don't believe that
can only be done by "rolling your own."
Jack Eifrig (email@example.com) The Johns Hopkins University, C.S. Dept.
Return to the
Search the comp.compilers archives again.