Re: Why put type information into syntax?

Michael Spencer <michael.prqa@indigo.ie> 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.
For example, the declarations
        int x;
and
        foo y;
have to be treated similarly, even though int is a keyword and foo
isn't. The typical workaround, as I understand it, for this is to
pretend that foo is a keyword if it's a typedef name -- *unless* it's
used as a new name in an inner scope. This typically requires
feedback to the lexical analyzer from the parser and the symbol table.


Perhaps your backtracking LR parser generator takes care of some of
this for you, but I believe there are cases that *can't* be resolved
without feedback from the symbol table. For example, how does your
grammar handle the following?


{
        typedef int foo;
        foo(x); /* This is a variable declaration. */
        bar(y); /* This is a function call.
}


The C family of languages are pretty much stuck with this kind of
ambiguity. In some other languages, the syntax is defined so that
*all* type names are identifiers, including the predefined ones, and
there is no such ambiguity. The Ada equivalent of the above is:


declare
        subtype Foo is Integer; -- "Integer" is an identifer, not a keyword
        X : Foo;
begin
        Bar(Y);
end;


--
Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>

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