Path: csiph.com!news.mixmin.net!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: alt.os.development Subject: Re: C parser ramblings, language design, etc Date: Sun, 13 Sep 2015 20:30:41 -0400 Organization: Aioe.org NNTP Server Lines: 76 Message-ID: References: NNTP-Posting-Host: n4wpt9zq8xR26Ttf9mo2BA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com alt.os.development:8798 On Sun, 13 Sep 2015 14:02:06 -0400, James Harris wrote: > "Rod Pemberton" wrote in message > news:op.x4wcoua0yfako5@localhost... >> On Sat, 12 Sep 2015 08:49:21 -0400, James Harris >> wrote: >>> "Rod Pemberton" wrote in message >>> news:op.x4tmp0ssyfako5@localhost... >> That works for grammar based parsers. That make not work >> for others which might detect a 'while' too early, without >> an easy way to track scope level, such as braces for a compound >> statement. They would need a method to track and pair do's >> and while's correctly. Solutions like counters and flags >> might not work, i.e., may need stack or state-machine. > > There are areas where parsing C is difficult but this isn't one of them. > Consider a typical simple hand-written parser which includes the > following code. > > if (token == DO) { > skip(); /* Skip the DO keyword */ > statement_parse(); /* Parse the statement following DO */ > if (token != WHILE) { /* Check for WHILE keyword */ > .... exception handling code .... > } else { > skip(); /* Skip the WHILE keyword */ > require(LPAREN); > expression_parse(); > require(RPAREN); > etc. > > In case it's not obvious the check (token != WHILE) on the fourth line > only takes place *after* statement_parse() returns. As such it would > find the *second* "while" in your example. The first "while" validly > begins a statement so it would be recognised in statement_parse() and > your example would parse properly and all without any special effort on > the part of the parser writer. ... > I cannot understand why you think that is hard to parse. Well, not all parsers work that way ... That's the point. How do you parse C with a simple parser? That's not simple enough, and it requires a certain type of design, i.e., grammar based and probably recursive descent, and uses look-ahead. So, your code example follows a grammar based design and looks ahead by calling statement_parse() upon finding "token == DO". Don't look ahead. So, if you can't check for "token == WHILE" or "token != WHILE" in the "token == DO" section, and you can't call statement_parse() there, what do you do for while, when you reach the "token == WHILE" section? How do you determine what type the 'while' is when you see 'while' or how do you identify enough information prior to that point to know which 'while' it is at that point? Think about single-pass where something is emitted immediately for each 'while' and only one token is known at a time. Also, you can't parse ahead or look ahead as you're doing by calling statement_parse(), since the code has already been parsed and stored as an AST of tokens, without that being done. You're just emitting code for each token in the AST. You can't backtrack or trace the AST either. So, when you come across a 'while', how do you know what type of while and whether it's part of a do-while or not? Assume this is a single-go, single-pass of the AST. All you have are the prior 'do', any braces, 'while', and semicolons, and/or the presence or absence of each thereof, to key off of, in order to determine the type of 'while' each 'while' is. Rod Pemberton -- Just how many texting and calendar apps does humanity need?