|[6 earlier articles]|
|Re: Why put type information into syntax? email@example.com (Michael Spencer) (2000-04-05)|
|Re: Why put type information into syntax? firstname.lastname@example.org (Rodney M. Bates) (2000-04-05)|
|Re: Why put type information into syntax? email@example.com (Keith Thompson) (2000-04-11)|
|Re: Why put type information into syntax? firstname.lastname@example.org (Ira D. Baxter) (2000-04-14)|
|Re: Why put type information into syntax? email@example.com (Robert A Duff) (2000-04-14)|
|Re: Why put type information into syntax? maratb@CS.Berkeley.EDU (Marat Boshernitsan) (2000-04-15)|
|Re: Why put type information into syntax? firstname.lastname@example.org (Michael Spencer) (2000-04-15)|
|From:||Michael Spencer <email@example.com>|
|Date:||15 Apr 2000 21:40:40 -0400|
|References:||00-03-133 00-03-146 00-04-017 00-04-050 00-04-073|
Keith Thompson wrote:
> Michael Spencer <firstname.lastname@example.org> writes:
> > More importantly, in C++, the built-in type keywords prevent parse
> > conflicts. They do in my grammar. I am using a backtracking LR
> > parser generator to parse C++ (since I need infinite lookahead). So I
> > am guessing anyway on conflicts. But I take a slight penalty every
> > time I do so, so I do not want to guess more than I have to.
> In either C or C++, the fact that the names of the predefined types
> are keywords (or sequences of keywords) doesn't really make parsing
> any easier, since the names of user-defined types are *not* keywords.
Consider this example:
typedef int A, B, C;
void foo ()
A B (C);
int long (C);
Initially, A B and C are all types. B is then declared as an extern
function taking type C and returning type A. Then, because "int" and
"long" are built-in *keywords*, C is declared as an object of type
"long int". If you group built-in type keywords with user-defined
types, don't you get the wrong answer? And only one token lookahead
is needed ...
You do not have this problem in Java.
Return to the
Search the comp.compilers archives again.