Re: Building a parse tree that reflects C Semantics

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

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