problem with C grammar

"A.T.Hofkamp" <a.t.hofkamp@tue.nl>
30 May 2006 18:40:16 -0400

          From comp.compilers

Related articles
problem with C grammar the.malfunction@googlemail.com (the.malfunction@googlemail.com) (2006-05-26)
Re: problem with C grammar ik@unicals.com (Ivan A. Kosarev) (2006-05-26)
Re: problem with C grammar DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-05-30)
Re: problem with C grammar cfc@shell01.TheWorld.com (Chris F Clark) (2006-05-30)
problem with C grammar a.t.hofkamp@tue.nl (A.T.Hofkamp) (2006-05-30)
Re: problem with C grammar rsc@swtch.com (Russ Cox) (2006-05-30)
Re: problem with C grammar idbaxter@semdesigns.com (Ira Baxter) (2006-06-03)
Re: problem with C grammar hebisch@math.uni.wroc.pl (Waldek Hebisch) (2006-06-03)
Re: problem with C grammar mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2006-06-05)
| List of all articles for this month |

From: "A.T.Hofkamp" <a.t.hofkamp@tue.nl>
Newsgroups: comp.compilers
Date: 30 May 2006 18:40:16 -0400
Organization: Compilers Central
References: 06-05-078 06-05-082
Keywords: C, syntax
Posted-Date: 30 May 2006 18:40:16 EDT

Hello all,


<the.malfunction@googlemail.com> wrote


  > As it seems, the lexical scanner is proposed to analyse whether an
  > identifier is a type or not. I rather would like to let the parser do
  > this job. Is there any way to change the grammar such that I can use
  > IDENTIFIER instead of TYPE_NAME here without having all those conflicts?


As Ivan A. Kosarev already stated, you can neither do this in the scanner nor
in the parser, you need semantical information to decide which parse variant
you should pick.


yacc & friends are not designed to handle this situation, although you can
work around this limiation if you feed semantical information back to the
parser and scanner. That does imply however that you will get an intertwined
scanner/parser/type checker.


If you dislike the idea of having the syntactical phase and semantical phase
intertwined, you may want to use a parser that delivers a parse forest (that
is, all parse trees derivable from the grammar for your input) instead of a
single tree. In the (seperate) semantical phase you can then decide which
trees of the forest you should use.


Two approaches that do this are


1. T.A. Wagner and S.L. Graham, Incremental analysis of real programming
languages. In proceedings of 1997 ACM SIGPLAN conference om Programming
language design and implementation, pages 31--43, ACM Press 1997


2. P. Klint and E. Visser, Using filters for the disambiguation of
context-free grammars, In G. Pighizzini and P. San Pietro, editors Proc.
ASMICS Workshop on Parsing Theory, pages 1--20, Milano Italy, 1994, Tech Rep
126-1994, Dipartimento di Scienze dell'Informazione, Universit\`a di Milano.


Of the latter, there is also an implementation, described in


M.G.J. van den Brand, S. Klusener, L. Moonen, and J.J. Vinju. Generalized
Parsing and Term Rewriting: Semantics Driven Disambiguation, in: Proceedings
of Third Workshop on Language Descriptions, Tools and Applications (LDTA'2003)
(eds. B.R. Bryant and J. Saraiva), volume 82 of Electronic Notes in
Theoretical Computer Science, Elsevier, 2003.




Albert


Post a followup to this message

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