Re: Re: Bug #838 Updated: Parser error in nested if

From: Date: Fri, 09 Oct 1998 16:55:00 +0000
Subject: Re: Re: Bug #838 Updated: Parser error in nested if
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-1769@lists.php.net to get a copy of this message
> Nope, it's not clear at all, and it's impossible to implement using an LALR > parser. Why is it not 'clear'? Because compilers aren't human beings and > can't apply intelligence. The parser has a working set of rules, with > rules of what to do in each case, using one lookahead token at the most. I know nothing about LALR, i only remember some theorics i learned in my old school times, so perhaps all what i'm going to say is stupid or perhaps i'm right and you missunderstood what i was saying. Theese are the rules i found in language-parser.y: | IF '(' expr ')' { cs_start_if (&$3 _INLINE_TLS); } statement elseif_list else_single { cs_end_if ( _INLINE_TLS_VOID); } | IF '(' expr ')' ':' { cs_start_if (&$3 _INLINE_TLS); } statement_list new_elseif_list new_else_single { cs_end_if ( _INLINE_TLS_VOID); } ENDIF ';' So, rules for colon if's and non colon if's are completely different. except for the cs_start_if, cs_end_if. I deduce (correct me if i'm wrong) that theese functions register the nesting if's. What i'm saying is that a colon if is a different instruction (a different language construct ) that a non colon if. If i'm right, the register functions must be different. Considere the language construct AF like the colon IF: AF '(' expr ')' ':' { cs_start_af (&$3 _INLINE_TLS); } statement_list new_elseaf_list new_elsea_single { cs_end_af ( _INLINE_TLS_VOID); } ENDAF ';' Then if i've understood the semmantics, this construction is correct: AF ($a==1): if ($b==2) echo "hello world"; ELSEAF ($a==2): echo "hello world"; ENDAF; Can you do that without changing IF by AF or am i completely obfuscated? > We've designed the language to use the standard solution for the dangling > else problem, which means that an else (or an elseif) applies to the least > recently nested if. When the parser spots an else statement, it expects it > to match the least recently nested if. It doesn't scan the whole block and > tries to make sense out of it. Of course, you could do that, but it > wouldn't have been an LALR parser and it would have been slower by orders > of magnitude (all popular languages can be described by LALR grammars, > including C, Perl, Java and just about anything else you can think of). It > expects you to follow the language grammar, and an else (or elseif) at that > spot is supposed to match that last if. Because of that, it expects that > else to have the same syntax as the last if, i.e., if the last if wasn't > using colon mode, the else shouldn't either. Since that's not the case, it > results in a parse error. > > Zeev > -- > Zeev Suraski <zeev@php.net> > For a PGP public key, finger bourbon@netvision.net.il > > Antonio Garcia Mari AT4.net Internet y Comunicación http://www.at4.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net

« previous php.dev (#1769) next »