LALR(1) GRAMMAR

Problem #4: Array Type versus Array Access

19.1.4

ResultType:

Type

void

Now consider the partial input:

class Problem3 { int julie

Note that, in this simple example, no

Modifiers

 are present. When the parser is

considering the token

int

, with one token lookahead to symbol

julie

, it cannot

yet tell whether this will be a field declaration such as:

int julie = 14;

or a method declaration such as:

int julie(String art) { return art.length(); }

Therefore, after the parser reduces

int

 to the nonterminal

Type

, it cannot tell with

only one token lookahead whether

Type

 should be further reduced to

ResultType

(for a method declaration) or left alone (for a field declaration). Therefore, the

productions shown above result in a grammar that is not LALR(1).

The solution is to eliminate the

ResultType

 production and to have separate

alternatives for

MethodHeader

:

MethodHeader:

Modifiers

opt

Type MethodDeclarator Throws

opt

Modifiers

opt

 void

MethodDeclarator Throws

opt

This allows the parser to reduce

int

 to

Type

 and then leave it as is, delaying

the decision as to whether a field declaration or method declaration is in progress.

19.1.4   Problem #4: Array Type versus Array Access

Consider the productions (shown after problem #1 has been corrected):

ArrayType:

Type

 [ ]

and:

ArrayAccess:

Name

 [

Expression

 ]

PrimaryNoNewArray

 [

Expression

 ]

Now consider the partial input:

437