Re: Java 2.0 Grammar Problems

Kees van Reeuwijk <C.vanReeuwijk@twi.tudelft.nl>
23 Feb 2001 00:06:47 -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: Kees van Reeuwijk <C.vanReeuwijk@twi.tudelft.nl>
Newsgroups: comp.compilers
Date: 23 Feb 2001 00:06:47 -0500
Organization: Delft University of Technology
References: 01-02-040 01-02-081
Keywords: Java, parse
Posted-Date: 23 Feb 2001 00:06:47 EST

On 15 Feb 2001 00:44:01 -0500, Kees van Reeuwijk
<C.vanReeuwijk@twi.tudelft.nl> wrote:


>The grammar in the appendix of JLS2 indeed has problems. The ambiguity
>you showed in your message is an example, and there are other issues. If
>someone is interested I can post the bug reports I sent to Sun about
>this.


To follow up on my own post (sorry), here is the bug report I sent Sun
about the JLS2 grammar appendix. I suspect I haven't spotted all bugs in
this grammar...


-------------------------


Dear Sir,


I have found a number errors in the Java Language Specification 2nd
edition. In particular, I found a number of significant problems in
chapter 18 (Syntax).


I have not been able to find any errata for JLS2 on your website; if
I've missed something I would be very interested to know.


This is the list of errors I've found:




* Page 193, 3rd rule of the grammar of ExplicitConstructorInvocation


Both the '.' and the keyword 'super' are terminals of the grammar,
and should be set in typewriter font (and separated with spaces).


There are other places where a similar problem occurs.




* Chapter 18, introduction.


It is implied that the syntax presented in this chapter is more suited
to be used in a parser. As a writer of a Java compiler, I have to
disagree with this. Apart from the errors (see below), the grammar
is unsuitable for use in a parser that does more than just accept
correct Java, and reject incorrect Java. For example, the production
IdentifierSuffix lumps together language constructs that a compiler
would want to keep separate. There are many examples of this.


Also, it is confusing that this chapter changes the notation for
optional occurences and lists of occurences.




* Page 450, grammar rules for Expression1 and Expression1Rest


Both rules make the part "'?' Expression ':' Expression1"
optional, which introduces a (trivial) ambiguity.


Also, why not absorb the rule for Expression1Rest in the rule
for Expression1? It is clearer and compacter.




* Page 450, grammar rule for Expression2Rest


The second production is incorrect, the term `Expression3' should be
deleted.


Again, why not absorb the grammar rule in the Expression2 rule?




* Page 450-451, grammar rule for Infixop


The precedence and binding rules for these operators are not specified,
making expressions such as 1+2*3 and 1-2-3 ambiguous.




* Page 451, grammar rule for Expression3, second production


The nonterminal 'Expr' is not defined. Surely this should be
'Expression'?




* Page 451, grammar rule for Primary, production starting with
Identifier


The this grammar rule contradicts the rule on page 327, since it allows
a single Identifier (i.e. a simple name such as 'cars_passed') as
a Primary. The grammar rules at page 327 do not allow this.


The grammar on page 451 is presumably correct, since it allows an
expression such as 'outerclass.new innerclass()', which is not allowed
using the grammar rule on page 327.




* Page 451, grammar rules Expression3 and Primary


The productions:


        Expression3: Primary { Selector } { PostfixOp }
        Primary: Identifier { '.' Identifier } [ IdentifierSuffix
]


cause considerable ambiguity. For example, the expression


        x.new inner()


can be produced as:


Expression3:


        x . new inner ()
        - -------------- -
        | | +-> { PostfixOp }
        | +---------> { Selector }
        +------------------> Primary


Selector:


        . new inner ()
        - --- --------
        | | +---------> InnerCreator
        | +---------------> 'new'
        +------------------> '.'


or as:


Expression3:


      x . new inner ()
      ---------------- - -
| | +--> { PostfixOp }
                    | +----> { Selector }
+--------------> Primary


Primary:
      x . new inner ()
      - - --------------
      | | +----------> [ IdentifierSuffix ]
      | +------------------> { . Identifier }
      +--------------------> Identifier






* Page 451, grammar rule IdentifierSuffix


This a misnomer, since it also describes the suffix of qualified
names. Why not call this nonterminal 'NamePrimarySuffix'?




* Page 452, grammar rule BasicType


Since throughout the rest of the book (including the 'inline'
grammar rules) the types are called 'primitive types', this is,
a very unexpected name.




* Page 453, grammar rules BlockStatement and Statement


Both have a production
        '[ Identifier ':' ] Statement


thereby introducing an ambiguity.




* Page 453, grammar rule Statement


The productions for 'break', and 'continue' lack a terminating ';',
whereas the 'throw' and 'return' productions do have them. As far as I
can tell, only the 'throw' and 'return' are correct.




* Page 453, grammar rule Statement


The nonterminal 'ExpressionStatement' is not defined in this chapter,
only in section 14.8.


--
Kees van Reeuwijk, Delft University of Technology
http://www.pds.twi.tudelft.nl/~reeuwijk


Post a followup to this message

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