Re: Why put type information into syntax?

Robert A Duff <world!bobduff@uunet.uu.net>
14 Apr 2000 23:44:19 -0400

          From comp.compilers

Related articles
[4 earlier articles]
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: Robert A Duff <world!bobduff@uunet.uu.net>
Newsgroups: comp.compilers
Date: 14 Apr 2000 23:44:19 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 00-03-133 00-03-146 00-04-017 00-04-050 00-04-073
Keywords: types, comment

Keith Thompson <kst@cts.com> writes:


> 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.
> }


Would it be possible to deal with this by having the parser build
trees that retain the ambiguity, and then resolve it during a separate
semantic-analysis tree walk? Eg, in the above example, build a tree
that represents "a var decl or a function call", and then walk the
tree, using a symbol table to help transform it into one or the other?


I suspect not...


- Bob
[Sure, that's what Earley parsers do, but the performance hit can be
phenomenal. -John]


Post a followup to this message

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