[comp.compilers] Request comments on text.

johnl@ima.UUCP (07/02/87)

Someone suggested to me that the Trembley and Sorenson text is a good
replacement for Aho, Sethi and Ullman.

Questions:
	(1)  Do you agree with above?
	(2)  Can you suggest a replacement for ASU?
[I'm not familiar with Trembley and Sorenson, but is there any particular
reason not to use the dragon book? -John]
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request

lm@cottage.WISC.EDU (Larry McVoy) (07/04/87)

>[I'm not familiar with Trembley and Sorenson, but is there any particular
>reason not to use the dragon book? -John]

Yeah, there is.  It's a pain to read.  And it doesn't really address
the problems very well.  While writing this article I looked through
the book again to see if I was inserting foot in mouth.  Nope.  Look up
symbol tables for a moment.  Most of the information there is about
data structures i.e., hash tables and string storage.  Why is this
here?  It's a waste of the reader's time - anyone reading this book
will know about linked lists.  And where is the info about the purpose
of the symbol table?  Well, they say stuff about names and reference
counts and leave you to find out how it really works later.  What about
separate compilation?  Debugger support?  External uses of the symbol
table (name list)?  Etc, etc?

Get my point?  The book is lots of theory, lots of needless information,
and not enough practical necessary information.  Fisher's book is better.
Logothetis's book will be better (if he ever gets it done).

Larry McVoy 	        lm@cottage.wisc.edu  or  uwvax!mcvoy
[Stay tuned for lots more comments on this topic.  -John]
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request

mason@tmsoft.UUCP (Dave Mason) (07/04/87)

In article <252@hubcap.UUCP> steve@hubcap.clemson.edu (Dennis Stevenson) writes:
>Someone suggested to me that the Trembley and Sorenson text is a good
>replacement for Aho, Sethi and Ullman.

I will be using Tremblay & Sorenson for the 3rd year this fall for an
undergraduate (4th year, Applied Computer Science) Compiler Design &
Implementation course.

I originally adopted it because the older Dragon Book was getting rather long
in the tooth, and the new one hadn't arrived yet.  I have since examined ASU,
though perhaps in somewhat less detail, and haven't changed my mind.

I feel T&S is better for MY students because it is somewhat more accessible
(perhaps a bit less formal/mathematical). It also has a more balanced
treatment of ad hoc vs yacc based parsing. As this course has been taught on
(and many of our students go on to) a relatively tool-poor environment
(VM/CMS), heavy emphasis on yacc and family are less desirable than they
might be in a totally Unix world. I also like the structure of the book a bit
better, but that's personal taste.

Of course, I'm never totally satisfied, so look forward to hearing of other
texts.
	../Dave Mason,
	..!{utzoo seismo!mnetor utcsri utgpu lsuc}!tmsoft!mason
	..!{utzoo seismo!mnetor!tmsoft utcsri utgpu lsuc}!ryesone!mason
	FCTY7053@RYERSON.BITNET
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request

jbn@glacier.STANFORD.EDU (John B. Nagle) (07/05/87)

    The "dragon book", ("Principles of Compiler Design"), is a bit weak
in the optimization area.  There's an extensive treatise on some of the
applicable graph theory, but not much guidance about what really ought
to be in an optimizing compiler and how to organize it.

    There's a recent book published by Digital Press (unfortunately the
title escapes me) which describes the optimizer for the VAX PL/1 and C
compilers in some detail.  This book is weak on theory but gives a
clear idea of what really goes on inside a big compiler.
[It's "Engineering a Compiler: VAX-11 Code Generation and Optimization,"
by Anklam et al.  It talks in considerable detail about the VAX PL/I code
generator, but hardly at all about the front end which they bought from
someone else.  -John]

    After reading both of the above, one should have an idea of how
to approach the problem.  (Given the present glut of mediocre compilers,
there's not much reason to write another one rather than porting something
widely available, unless your needs are very specialized.)


					John Nagle
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request

johnl@ima.UUCP (07/06/87)

In article <252@hubcap.UUCP> steve@hubcap.clemson.edu (Dennis Stevenson) writes:
>Someone suggested to me that the Trembley and Sorenson text is a good
>replacement for Aho, Sethi and Ullman.

Well, I'm on the other side - I've used Tremblay and Sorenson, but not the
Dragon book.  In fact, I took two senior half-classes (Formal Languages /
Parsing and Compiler Writing (mostly code generation)) from J.P. Tremblay.

T&S (The Theory and Practice of Compiler Writing, McGraw Hill, 1985) gives a
good formal overview of different parsers (LR, SLR, LALR; LL(1)) and the
algorithms used both in parser generators and in the parsers themselves.
It has chapters on machine-independent and machine-dependent optimisation,
though we didn't cover them so I can't really comment.  It has plenty of
examples.

People who have taken formal languages as a theory class (push-down automata
etc.) may want to skip some of the early chapters which review this stuff.

It also has a chapter on compiler-compiler systems, covering Yacc and things
like it (including ATS, an attributed LL(1) parser generator developed
here); there is some coverage of automatic code-generator generators, which
they hope to extend in a revision of the text some time in the next few
years.

Tou can also get "An Implementation Guide to Compiler Writing", a paperback
which contains the complete (PL/1, unfortunately) implementation of an LL(1)
table driven parser and code generator for a simple programming language.
The authors have expressed the intent to re-write this using C, with ATS for
the parser.  Who knows when...

All in all I liked the text; it's big, but then so is the Dragon book.  Much
of the detail is set up so it can be skipped in a course and used for
reference later, so the size isn't really a problem.
-- 
 - irving -   (reid@sask.uucp or {alberta, ihnp4, utcsri}!sask!reid)
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request

stevev@tekchips.tek.com (Steve Vegdahl) (07/06/87)

>[I'm not familiar with Trembley and Sorenson, but is there any particular
>reason not to use the dragon book? -John]

In response to John's question, I can think of a number of reasons to not
use the dragon book.  Before I list the ones I can think of, let me
preface this with some background.

I have taught both the front- and back-end halves of a two-quarter
graduate compiler course using the dragon book (1986 edition).  Non-
technical circumstances made the use of the dragon book nearly manditory,
so I spent virtually no time searching for other options.  DESPITE THE FACT
THAT FOLLOWING TEXT DISCUSSES WEAKNESSES OF THE DRAGON BOOK, I THINK THAT
OVERALL, IT IS A GOOD COMPILER TEXT.  My compiler experience has been in
compilers for microcode target architectures, and for "advanced" languages
(e.g., Lisp, Smalltalk) for more traditional architectures.

The following describe what I perceive to be weaknesses of the dragon book.
These weaknesses can be largely summed up in the sentence "the dragon book
teaches you how to write a C compiler for a traditional architecture".

  * Although I feel that the treatment of the lexical and syntax analysis
    if very nice, the discussion of semantic analysis lacks a bit of
    overall perspective, being treated in a somewhat ad hoc fashion.  The
    treatement of back-end issues (e.g., code-generation, optimization)
    is even less unified.
  * The issue of automatic garbage-collection is all but ignored.  It
    is actually ignored in two ways.  First, little treatment of garbage
    collection algorithms is given.  (ONE PAGE to discuss both reference-
    counting and marking.  I believe that they do not even mention copying
    garbage-collectors and generation-scavenging, although the latter may
    have been too recent for their printing schedules.)  Secondly, the
    presence of a garbage-collector in an implementation pervades (virtually)
    the entire compiler.  For example, non-standard data-representations
    are typically used; certain optimizations may be disallowed; registers
    are typically divided into "rooted" and "non-rooted" classes, with
    restrictions on how each is used.  The pervasiveness of the garbage-
    collection on the entire compiler-writing process is ignored by the
    book.
  * Little (if any) treatment is given to supporting first-class procedures
    and continuations.
  * Although type-inference (a la ML) is discussed, the treatment given
    is too shallow.  Subtleties arise when implementing type-inference
    that are not addressed.
  * No (little?) discussion of code-reorganization that is now common in
    many RISC-style compilers.
  * A good programming environment is becoming increasingly recognized
    as a fundamental piece of a language implemenation.  The book does
    not really address this subject.  Quite a bit of good work has
    been done, for example, in the area of incremental compilation
    (e.g., Reps).

OK, there's my (partial?) list of "gripes" about the dragon book.  Let
me again say that this should not be (mis)construed as a statement that
the dragon book is a lousy book; on the contrary, I think it's a very
informative, well-written book.  If a book came out, however, that
addressed some of the above issues, it would be worth considering as
a replacement for the dragon book.  I do not know whether any such book
exists.  In particular, I am not familiar with Trembley and Sorenson.
(Who publishes their book?)

		Steve Vegdahl
		Computer Research Lab
		Tektronix Labs
		Beaverton, Oregon
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request

ma_jpb@ux63.bath.ac.uk (Bennett) (07/13/87)

In teaching the final year compiler course here, I recommend Aho, Sethi and
Ullman as the main text. I have no complaints about the content or style, and
have had no complaints from students either. The only faults I have been able
to find have been the odd typesetting error making an explanation unclear. I
should point out that its predecessor (Aho and Ullman) is not as good, being
very weak on code generation.

At the same time I recommend Tremblay and Sorensen as an alternative. This book
seems to have one or two advantages:

a) In the UK it is cheaper

b) It has an early chapter on programming language design, which I think is
   useful background for compiler writers.

c) It covers compiler-compilers other than YACC.

d) It is slightly more recent

The handling of grammars is perhaps a little more formal than Aho et. al. The
only argument against is that it is not as well established as Aho et. al., and
may not be as widely available. My personal inclination is to let students
select whichever book they prefer. It shouldn't affect them, since my lectures
aren't based on any one book.

J.P. Bennett                        Tel:   +44 225 826891
School of Mathematical Sciences     Telex: 449097 UOBATH G
University of Bath                  Fax:   +44 225 62508 (Group 3)
Bath BA2 7AY, England               Arpa:  jpb@maths.bath.ac.uk
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request

johnl@ima.UUCP (07/16/87)

In article <609@ima.ISC.COM> stevev@tekchips.tek.com (Steve Vegdahl) writes:
>[on dragon book weaknesses ...] These weaknesses can be largely summed up
>in the sentence "the dragon book teaches you how to write a C compiler for
>a traditional architecture".

Amen.  It is of course a mere coincidence that all the authors are associated
with Bell Labs... :-)  I would really like to see a text that covered
Lisp/Prolog/Smalltalk implementation in general, both runtime and compilation.
Alas, such a beast does not exist, although a hardworking instructor could
assemble papers and book chapters, and get decent coverage.  Peter Henderson's
book "Functional Programming: Application and Implementation" (Prentice-Hall,
1980) has some good material in the back, including an object file to boot
up your compiler with (!).  Allen's "Anatomy of Lisp" is well-known but
obscure in places, and the only material on optimization is recent conference
papers and source code.

>  * A good programming environment is becoming increasingly recognized
>    as a fundamental piece of a language implemenation.  The book does
>    not really address this subject.  Quite a bit of good work has
>    been done, for example, in the area of incremental compilation
>    (e.g., Reps).

Hoo boy, I might consider writing a text on straight language implementation
(if I ever finish my thesis :-( ), but environments are a deep dark morass.
It seems risky to include a lot of relatively undigested recent literature
in a text that needs to teach basic principles and stay relevant for a few
years.  Still, it's probably about time for someone to get started.  Is there
anybody out there writing a book on environment implementation?

							stan shebs
							shebs@cs.utah.edu
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request