Re: Java 2.0 Grammar Problems

Dr_Feriozi@prodigy.net
1 Mar 2001 02:36:30 -0500

          From comp.compilers

Related articles
Java 2.0 Grammar Problems schoettner@informatik.uni-ulm.de (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 maslen@pobox.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 pmb@dina.kvl.dk (Peter Bertelsen) (2001-02-25)
Re: Java 2.0 Grammar Problems Dr_Feriozi@prodigy.net (2001-03-01)
| List of all articles for this month |
From: Dr_Feriozi@prodigy.net
Newsgroups: comp.compilers
Date: 1 Mar 2001 02:36:30 -0500
Organization: Compilers Central
References: 01-02-040
Keywords: Java, parse
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
hardware company.


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.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.