Re: Avoiding inherited attributes in bottom-up parsing

Chris F Clark <world!cfc@uunet.uu.net>
28 Aug 1999 02:10:05 -0400

          From comp.compilers

Related articles
Avoiding inherited attributes in bottom-up parsing toca@serop.abb.se (Tobias Carlsson) (1999-08-27)
Re: Avoiding inherited attributes in bottom-up parsing rkrayhawk@aol.com (1999-08-28)
Re: Avoiding inherited attributes in bottom-up parsing world!cfc@uunet.uu.net (Chris F Clark) (1999-08-28)
Re: Avoiding inherited attributes in bottom-up parsing torbenm@diku.dk (1999-09-05)
Re: Avoiding inherited attributes in bottom-up parsing martin.jourdan@directprovider.net (1999-09-10)
Avoiding inherited attributes in bottom-up parsing sassa@is.titech.ac.jp (1999-09-10)
| List of all articles for this month |
From: Chris F Clark <world!cfc@uunet.uu.net>
Newsgroups: comp.compilers
Date: 28 Aug 1999 02:10:05 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 99-08-104
Keywords: parse, attribute

> In the dragon book one can read about evaluation of inherited attributes
> in bottom-up parsing. I think that inherited attributes should be
> avoided in bottom up parsing.
> To get access to inherited attributes (without using globals), one must
. . .
> I think this way makes the grammar easier to read and there's no need
> for inherited attributes, since you install attributes in the symbol
> table as they appear in the grammar. That increases understandability
> a lot.
. . .


Your symbol table solution is exactly equivalent to using global
variables. You are using it to hold synthesized attributes (the list
of variables to be decorated with types), but it is still a global
variable holding an attribute. That is not necessarily bad. In fact,
your solution is fine and I've seen it used very successfully in
different compilers.


However, it is still equivalent to using global variables. You're
just using the symbol table to hold the current value of the global
variables. That's just the nature of the problem.


Either:
1) the solution must be solved entirely with synthesized
attributes, in which case the declaration rule puts the types
and the variables together (as it does in your case; the fact
that some of it is happening behind your back, does not change
the process)


2) the solution uses both synthesized and inherited attributes
and some part of the declaration adds one type to one variable.


Note, you must use some synthesized attributes, because either the
list of variables or the type must percolate up the tree to the
declaration rule before it can become an inherited attribute and
applied to the other side.


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. CompuServe : 74252,1375
3 Proctor Street voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)
------------------------------------------------------------------------------
Web Site in Progress: Web Site : http://world.std.com/~compres


Post a followup to this message

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