Re: Lex , Yacc Problem

rkrayhawk@aol.com (RKRayhawk)
22 Sep 2003 23:44:46 -0400

          From comp.compilers

Related articles
Lex , Yacc Problem dbansidhar@indiainfo.com (2003-09-14)
Re: Lex , Yacc Problem paulchen32@freenet.de (Jens Kallup) (2003-09-22)
Re: Lex , Yacc Problem rkrayhawk@aol.com (2003-09-22)
Re: Lex , Yacc Problem blackmarlin@asean-mail.com (2003-09-23)
| List of all articles for this month |

From: rkrayhawk@aol.com (RKRayhawk)
Newsgroups: comp.compilers
Date: 22 Sep 2003 23:44:46 -0400
Organization: AOL http://www.aol.com
References: 03-09-051
Keywords: parse, lex
Posted-Date: 22 Sep 2003 23:44:46 EDT

dbansidhar@indiainfo.com (Bansidhar)
Date: 9/14/03 4:02 PM EST


<<
Some how I come to know I am in #if 0 block which
parsing for 2nd #if statement.
>>


If the meaning of 'to know' is for the lexer to know, then don't try. You
should parse the text in a grammar and let it push and pop current information
to track the structure of your input source file.


The lexer's job is to find the pieces. The grammar's job is to see if it has a
good structure.


Track your structure, and depth into a structure in the grammar processor. Keep
tracking the structure of the source text, even after hitting nullifying
directives; you still need the full depth of everything that follows.


Finding the structure of your file is different than doing something about that
structure. Wait until you have the whole structure to imlement it.


You can achieve states in the grammar that actually quickly shut down code
generations upon the first #if 0, but you still need to keep parsing inward and
inward and inward.


Part of your code looks like you want to be able to handle inperfectly balanced
parens. Your post could mean two things.


First maybe you want just generally to deal with this kind of thing. The #if 0
discussion is then just confusing you. You need to ask about how to recover
from errors in the input text: particularly how to end long sequences that are
getting confused because a close paren was missing. That is not really related
to the conditional assembler directives (although, depending on your language
definition, you can sometimes get a lexical partical, such as the _next_
directtive that starts with a pound sign (the next #if ...) to terminate and
reduce the preceding erroneous sequence). Ask about error recovery if you are
not yet into that.


A second interpretation of your post is that somehow, becuase of a preceding
#if 0, then subsequent text might 'legally' be allowed to be malformed (such as
having inbalanced parens). If you are in control of the language definition,
then, perhaps consider not doing that at all. If this is a given let us know
(if acceptable) what language definition has lead you to this problem. Either
an alternative understanding might be present in the field, or a solution is
known. But you post looks unusual, in that a conditional compiler directive, or
conditional assembler directive; _normally_ does not suspend the need for the
subsequent text to conform to the basic language pattern rules (specifially, I
have never heard of a language that drops balanced paren requirements, upon a
condition directive ... but it is a big and wonderful world).


Best Wishes,
Bob Rayhawk
RKRayhawk@aol.com


Post a followup to this message

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