Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!harpo!ihnp4!fortune!rpw3
From: rpw3@fortune.UUCP
Newsgroups: net.micro.apple
Subject: Re: LL(1) parser for an apple. (are you - (nf)
Message-ID: <3320@fortune.UUCP>
Date: Tue, 15-May-84 20:06:57 EDT
Article-I.D.: fortune.3320
Posted: Tue May 15 20:06:57 1984
Date-Received: Wed, 16-May-84 04:51:36 EDT
Sender: notes@fortune.UUCP
Organization: Fortune Systems, Redwood City, CA
Lines: 32

#R:sdccs7:-121900:fortune:22000002:000:1080
fortune!rpw3    May 15 17:03:00 1984

It also happens to be the case that IF the grammar is LL(1) or even
reasonably close, a recursive-descent parser is:

	1. Fast

	2. Easy to write, understand, and maintain

	3. Easy to embed semantics (and other misc. functions) at
	   the right point

	4. Capable of acceptable error-handling (assuming you want to
	   detect erros, not "fix" them)
	
	5. It mixes well with other parsing techniques which may want to
	   be used in parts of the language that may not be strictly LL(1).

The BLISS family of languages/compilers all (to my knowledge) use
recursive-descent for declarations and control structures, and
operator-precedence for expressions. They are also some of the
best optimizing compilers ever built. (It's not a complete non-sequitor,
as the common sub-expression recognition was done during syntax analysis.)
See Wulf, et. al., "The Design of an Optimizing Compiler" (Addison-Wesley).

Rob Warnock

UUCP:	{ihnp4,ucbvax!amd70,hpda,harpo,sri-unix,allegra}!fortune!rpw3
DDD:	(415)595-8444
USPS:	Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065