Re: Why put type information into syntax?

Keith Thompson <kst@cts.com>
11 Apr 2000 14:30:33 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: Why put type information into syntax? lex@cc.gatech.edu (2000-03-28)
Re: Why put type information into syntax? RobertADuffbobduff@world.std.com> (2000-03-28)
Re: Why put type information into syntax? tlh20@cam.ac.uk (Tim Harris) (2000-04-01)
Re: Why put type information into syntax? kst@cts.com (Keith Thompson) (2000-04-01)
Re: Why put type information into syntax? michael.prqa@indigo.ie (Michael Spencer) (2000-04-05)
Re: Why put type information into syntax? rod.bates@wichita.boeing.com (Rodney M. Bates) (2000-04-05)
Re: Why put type information into syntax? kst@cts.com (Keith Thompson) (2000-04-11)
Re: Why put type information into syntax? idbaxter@semdesigns.com (Ira D. Baxter) (2000-04-14)
Re: Why put type information into syntax? world!bobduff@uunet.uu.net (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? mspencer@eircom.net (Michael Spencer) (2000-04-15)
| List of all articles for this month |

From: Keith Thompson <kst@cts.com>
Newsgroups: comp.compilers
Date: 11 Apr 2000 14:30:33 -0400
Organization: CTS Network Services
References: 00-03-133 00-03-146 00-04-017 00-04-050
Keywords: parse, types

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>


Post a followup to this message

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