|Building C/C++ compilers email@example.com (Sigurd Lerstad) (2004-12-16)|
|Re: Building C/C++ compilers firstname.lastname@example.org (Vidar Hokstad) (2004-12-17)|
|Re: Building C/C++ compilers email@example.com (Robert J. Simpson) (2004-12-17)|
|Re: Building C/C++ compilers firstname.lastname@example.org (David Lindauer) (2004-12-17)|
|From:||"Vidar Hokstad" <email@example.com>|
|Date:||17 Dec 2004 00:28:53 -0500|
|Posted-Date:||17 Dec 2004 00:28:53 EST|
Sigurd Lerstad wrote:
> In the phase to produce Abstract Syntax Tree (AST) from the source.
> has a difficult case that has an amiguity
> g * h
> this can mean declare a variable pointer to g named h, or the
> multiplied with h;
> In the above mentioned book, Appel first builds a syntax tree and
> semantic analysis, i.e. type checking etc.
> but it seems to me that because of the above ambiguity, ast building
> semantic analysis must be performed at the same time ?
I haven't read the book in question, but with regards to building the
AST this really depends on HOW the AST is represented. If, on parsing
"g * h" the syntax tree just consists of some node for "*" with nodes
for "g" and "h" attached to it, without a clear indication of which
meaning of "*" applies, then no semantic analysis may be needed at that
stage, because as long as one of the uses are syntactically valid it
doesn't really make a huge difference.
If you wish to explicitly treat "pointer to" and "multiplication"
differently in your AST, then you'll need to do more work. Many people
would probably consider allowing the ambiguity described above in an
AST as a hack.
During semantic analysis you'd then have the information to infer which
use of "*" was meant, and may want to annotate the AST further to
simplify later user.
Return to the
Search the comp.compilers archives again.