Re: Building a parse tree that reflects C Semantics

"Rodney M. Bates" <rbates@southwind.net>
6 Nov 2002 11:45:48 -0500

          From comp.compilers

Related articles
Building a parse tree that reflects C Semantics vbdis@aol.com (VBDis) (2002-10-13)
Re: Building a parse tree that reflects C Semantics grosch@cocolab.de (Josef Grosch) (2002-10-18)
Re: Building a parse tree that reflects C Semantics idbaxter@semdesigns.com (Ira Baxter) (2002-10-20)
Re: Building a parse tree that reflects C Semantics whopkins@alpha2.csd.uwm.edu (Mark) (2002-10-20)
Re: Building a parse tree that reflects C Semantics rbates@southwind.net (Rodney M. Bates) (2002-10-20)
Re: Building a parse tree that reflects C Semantics david.thompson1@worldnet.att.net (David Thompson) (2002-10-25)
Re: Building a parse tree that reflects C Semantics rbates@southwind.net (Rodney M. Bates) (2002-11-06)
Re: Building a parse tree that reflects C Semantics idbaxter@semdesigns.com (Ira Baxter) (2002-11-07)
| List of all articles for this month |

From: "Rodney M. Bates" <rbates@southwind.net>
Newsgroups: comp.compilers
Date: 6 Nov 2002 11:45:48 -0500
Organization: EarthLink Inc. -- http://www.EarthLink.net
References: 02-10-058 02-10-086
Keywords: C, parse
Posted-Date: 06 Nov 2002 11:45:48 EST

Ira Baxter wrote:
>
> > We build tools that are intended to transform the program structure,
> for arbitrary source languages. We wish to write transforms that can
> be expressed in terms of the surface syntax of the language, e.g.,
>
> c = c + 1 ==> c++
>
> To do this, we desire that language fragments (patterns) be mapped to
> the same structures as entire programs;. So we've chosen a
> representation which optimizes on matching trees. We too chose trees
> to represent such structures, but not the "semantically oriented"
> ones, especially not ones with specialized representations such as bit
> vectors, because you can only produce such representations if you
> parse "larger chunks" (i.e., then entire specifier list). If you
> insist on this approach, it makes building either the fragment parser
> considerably more difficult (it has to understand how to build
> specialized representations, possibly in the face of not having enough
> information, e.g., build a partial bit vector), or the matcher more
> difficult (how do I match a fragment of a specifier list against a bit
> vector representing the entire list), or both.


I think I see your reasoning, but now you have gotten my curiosity up.
What sorts of meaningful pattern transformations could be written when:


1) The surface syntax is quite different from the deep semantics, and
2) The fragment in a pattern to be matched is too small to be able
      to define how it maps to deep semantics?


Or have I missed your meaning entirely?
--
Rodney M. Bates


Post a followup to this message

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