|Java 2.0 Grammar Problems firstname.lastname@example.org (Michael Schoettner) (2001-02-12)|
|Re: Java 2.0 Grammar Problems C.vanReeuwijk@twi.tudelft.nl (Kees van Reeuwijk) (2001-02-15)|
|Re: Java 2.0 Grammar Problems email@example.com (Thomas Maslen) (2001-02-17)|
|Re: Java 2.0 Grammar Problems C.vanReeuwijk@twi.tudelft.nl (Kees van Reeuwijk) (2001-02-23)|
|Re: Java 2.0 Grammar Problems firstname.lastname@example.org (Peter Bertelsen) (2001-02-25)|
|Re: Java 2.0 Grammar Problems Dr_Feriozi@prodigy.net (2001-03-01)|
|Date:||1 Mar 2001 02:36:30 -0500|
|Posted-Date:||01 Mar 2001 02:36:30 EST|
The grammar is very rough indeed. However, I found the soft copy saved
a lot of typing. And having a reference grammar is easier than
creating one from the description of the language, even with the
errors. Many of the problems were fairly obvious typos. Some of the
things mentioned were matters of taste in the choice of names, but
valid none the less. I am of course much more forgiving at this
point. I certainly did curse the more egregious errors in the grammar
during development. But then I remembered that Sun is, after all, a
This version of the grammar clearly has been rewritten to support top
down parsing. So, many of the productions have been left factored. This
explains things like the IdentifierSuffix productions.
I can think of two possible reasons why the operator precedence
productions were not included.
1. Clarity. These productions tend to overwhelm the more important parts
of the grammar. The rules are well known, so they are easy to add.
2. Other precedence techniques can be used.
The extra depth in the grammar that is the result of using productions
to perform operator precedence is quite a strain on recursive descent
parsers. Lots of function calls need to be made to establish
precedence. This is one area where table driven LL(k) parsers have an
advantage. The overhead incurred by winding through the production
hierarchy is very small.
Return to the
Search the comp.compilers archives again.