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






footer




 

 

 

 

 Home | About Us | Network | Services | Support | FAQ | Control Panel | Order Online | Sitemap | Contact

java hosting

 

Our partners: PHP: Hypertext Preprocessor Best Web Hosting Java Web Hosting Inexpensive Web Hosting  Jsp Web Hosting

Cheapest Web Hosting Jsp Hosting Cheap Hosting

Visionwebhosting.net Business web hosting division of Web Design Plus. All rights reserved