Customer Reviews

lex & yacc

5 star:		(16)
4 star:		(12)
3 star:		(3)
2 star:		(6)
1 star:		(1)

 

 

As with several other O'Reilly books, I found Lex & Yacc to be maddeningly uneven. The approach is to give a too-brief synopsis of the tool, then illustrate its use using a very specific example that, one suspects, is merely the handiest project the authors had available.

I had a fair bit of programming experience when I bought the book, but none with Lex or Yacc. Some fundamental questions came up during the course of my muddling through, and these were left unanswered. I actually got more insight into these tools from a ~20-page web site on the topic.

The reference chapters are organized alphabetically ("ambiguities & conflicts", "bugs", ..., "%ident declaration"), and in a way that does not help someone who is looking for a specific answer (in trying to find out about the possibility of more than one parser in a program, who would think to look under 'v' for "variant and multiple grammars"?). These 'reference chapters' seemed more like a place to dump the information not discussed elsewhere.

Maybe it's a lost cause, finding a comprehensive, well-written introduction to such an arcane topic, but I'm still looking.

To keep it simple, the book "Introduction to Compiler Construction in UNIX" introduces and explains LEX/YACC far better than this book. It uses a more realistic example and shows the error handling in more detail. This book is ok for a quick intro, but for a 'real" user, refer to the book I mentioned above.

This book was disappointing. I had hoped for a tutorial and reference on Lex/Yacc Flex/Bison for building language recognisers, but in the tradition of "yet another boring and useless reverse polish notation" calculator - it gives us a desktop infix expression calculator. (How could I have possibly guessed?)

The book presents some interesting material for those who want to parse SQL, but if you're eager to learn about translating programming languages, this book is nearly useless. It gives superficial and confusing treatment of language constructs like "if-then-else" statements, and gives only an exercise for recognising a function call and "playing it back." (I feel these are cop-outs.) It also fails to explain clearly how to construct unambiguous grammars, or use facilities for operator precedence or whatver to control the ambiguity.

To be fair, I am guessing this was meant as a reference for Lex/Yacc for those who already know how to construct language recognisers and have some knowledge of using these tools. But then why bother to give especially bad tutorial material in the early chapters if this were the case?

This books is also in need of a new edition.

There is too much repetition of basic ideas in the first few chapters of the book, and not enough coverage of more advanced topics (like how to use marker nonterminals, how to use $<>$ constructs, etc).

The discussion of shift/reduce and reduce/reduce conflicts in chaper 8 is pretty good though and would make a fine introduction for a beginner wanting to learn /basic/ concepts.

Good error handling is definitely a black art, but I still would have liked to have been given more information about it in chapter 9. The examples were also a bit too soft.

Chapters 4 and 5 have some interesting (and highly unusual)examples for scanning and parsing applications, but they do not show off many of the advanced capabilites of lex and yacc. What this book really needs are couple of examples that demonstrate how to overcome classic scanning and parsing horrors (like how to do type checking in, say, C); a chapter like this instead of one of chapters 4 or 5 would be great.

Even today lex and yacc are very important tools in the computer scientist's toolkit. They were designed 25 (or so) years ago, but /real/ documentation is still nonexistant. This means that unfortunately, this book is one of the best.

I think that the FSF's Bison manual is much better value for money. It also does not cover advanced topics in enough depth, but what is does explain, it explains quite clearly.

This book will get you writing language compilers in Lex and Yacc. It is clearly written, to the point, and has a wealth of useful information.

It should be supplemented with a more theoretical work, like Aho, Sethi and Ullman's book on compilers.

Firstly there are not many books on Lex & Yacc.
Unix programming by Kernighan & Pike provides
some necessary information but it is not sufficient
to write a complex parser or scanner. In these circumstances
this book acts like a God given gift for compiler developers.

The examples which introduce the tools are very good.
But the theory behind these examples is not well explained.
Probably NFA/DFA concepts add more strenght to the
book. Adding more and more concepts and examples
will make this as a unique book in the Market.

Many guys who desire jobs as compiler developers
follow this book. So some contemporary examples that
I expect from future editions of this book are
A) Parsing a Gate level design
B) A small simulator which simulates an analog/digital design
C) An assembler etc
D) Relational algebra tutor etc.

Hope the authors can consider this request.

I learned to use lex and yacc long ago, painfully and perhaps poorly, partly from snippets which may or may not have been good examples and partly from reading the generated scanning and parsing code. I imagine that my experience was typical. The old metaphor about how sausage is made is apt. And although I have since used other parser generators much more than I ever used bison, bison was the right tool for some recent projects. So I decided to take a look at John Levine's updated book, which is written in the helpfully assuring voice you'd expect, demonstrating experience though well chosen examples and seasoned with interesting historical notes.

General Observations:

* Levine makes no apologies for the tools. Where there be dragons, he offers practical advice on slaying them or -- better -- walking around them. (It seems like there was a Monty Python sketch about this, or should have been.)

* Generally well written, could have used some more editing to smooth out some convoluted bits.

* More than the usual number of errors, mostly minor and all readily fixable, in the examples.

* There is apparently no code available for download. This may not be a bad thing. I found myself thinking more than usual as I typed, which means I needed to go through the exercise. You're not going to learn how to parse and scan in the real world just by reading about it.

* The exercises are few but highly relevant. You should at least read them even if you have no time to do them.

* The index is good, but you probably won't need it.


Suggestions for Reading Order:

In general, each chapter read is expected to be read as a whole, from beginning to end. Internal back-references within chapters are frequent and effectively demand linear reading and comprehension. This seems to be a deliberate design choice, to avoid the need for more repetition than is absolutely essential. [Insert awful joke about left recursion here.]

The chapters, read as wholes, need not be read in ordinal order. This order worked well for me:

[1,] 2, 3, 7, 8


What You Get

Chapter 1 is the usual get-our-feet-wet chapter. If you don't like what you see, you're done.
Chapters 2 and 3 demonstrate how to apply flex and bison, respectively. Chapter 2 includes simple actions in the scanner, so that the examples *do* something. Old hands will recognize this; new students will see their patience rewarded in Chapter 3 where all but the simplest actions are placed in the parser, relieving the scanner of ill-suited tasks.

Chapter 4 presents a workable parser for SQL. It's an interesting choice and can be skipped if you're pressed for time.

Chapters 5 and 6 are useful references for flex and bison. These are not the typically disappointing rehash of man pages or online documentation. The information is clear, concise and full of essential observations and advice. You can skip these chapters but you will return to them. These two chapters are pretty much the manuals I wish I had when I started using lex and yacc.

Chapter 7 is one of the most coherent *practical* discussions of ambiguity and conflicts I've seen. It's about as good as possible without building the state machines, and Levine leverages the reports generated by bison to avoid discussion of first and follow sets. Instead Levine provides an informal and pragmatic pattern for reasoning about shift/reduce conflicts reported by bison, including the classic if/then/else anti-pattern. This is concise coaching which will help you anticipate and resolve common problems. Levine gently encourages the reader to think carefully about whether ambiguities may be a sign of bad language design and not just conflicts to be resolved by ad hoc rules.

Chapter 8 provides a brief but informative discussion of reporting and recovering from errors. If your language is ever going to have users, you'll have to deal with errors. Error-reporting is easy. Useful error-reporting is a little harder. And error-recovery is non-trivial for all but trivial languages. Levine provides some practical examples which serve to underscore the virtue of failing fast over flailing hard.

Chapter 9 collects some recent developments in flex and bison, some of which may be suitable for production. If you just need to get a parser going quickly and reliably in C for a simple language, or you can call C libraries, then flex and bison are your buddies. Levine provides a frank and fair assessment of the current (ca. 2009) support for implementing C++ parsers and scanners. Along with pure parsers and GLR parsing, these are advanced topics in the sense that their implementations in bison/flex are less mature than LALR targeting C implementation. Levine offers much practical advice which might be summed up as, "I could, but should I?" If the answer for your application is 'Yes, I need to cut against the historical grain of bison/flex,' then you'll do well to become familiar with some of the newer parser-generating kits which were created for that purpose. But if the significance of the question is not obvious, then this book will help you break it down into smaller parts and begin to answer it.

Overall, this is a must-read for anyone trying to make effective use of flex and bison. You could do it the hard way, but your job is going to be hard enough anyway. So you might as well get a good start from someone who knows the stuff inside and out. This book does that.

As someone who has written a number of programming language translators and who has read a number of books on compiler generation, I found that this book is very readable and gives the best introduction to compiler compilers I've ever seen.

In general this book is very good, and I would highly recommended it for anybody using tools like lex and yacc. It covers all the areas (both good and bad) of these tools. However, I find that the book is frustrating and incomplete in two ways :- (1) when it comes to solving some of the problems reported by such tools as lex and yacc, there is not enough of examples, especially less-trivial examples, and some of the more potentially obscure problems that can occur. (2) it is very frustrating that the page numbers listed in the index are out by 1 or 2 pages. In this era of technology this should not happen.

To me a great book flows into your mind, magically providing the information in the order you need it. Of course it depends on whose reading it, but this book, though well worth the 96 cents bargain bin price I paid for it, does not build the constructs in my head the way I'd like.

Authors should always proofread their books with novices, not the experts. Experts fill in the gaps as they read and don't notice if the logic is missing a link. In chap 2, "Using Lex", there is the sentence: "Lex itself doesn't produce an executable program; instead it translates the lex specification into a file containing a C routine called yylex(). Your program calls yylex() to run the lexer."

I waited with baited breath for what it means to "run the lexer". Does it return a token each time you call it? Does it analyze all the input then return? The text ignores this detail and merrily goes on into other details. The chapter is called "Using Lex", but the authors omit how you use it! Of course you can scrounge around in the examples and finally root it out, but a book should paint a crystal clear picture, get you oriented, then drop in the details to build your understanding.

The book looks so promising, sort of like the beauty of the original "The C Programming Language" by Kernighan and Ritchie, but disappoints in it's fragmented exposition.

I did take a compiler course with the "dragon book" years ago and write a parser, so I'm not totally in the dark, but I expected this book to lay the subject out in a much clearer way. But it is still a good book to have and read "offline".

I hope the authors take a crack at another edition and explain it all better.