Re: Re: Bug #838 Updated: Parser error in nested if
| From: | Antonio Garcia Mari | 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