🚀 go-pugleaf

In article <4ksfaq$jug@nntp1.best.com>, Zenin  <zenin@best.com> wrote:
 >Kazimir Kylheku <c2a192@ugrad.cs.ubc.ca> wrote:
 >	>snip<
 >: Actually I do program much. I wouldn't talk if I were you, read on...
 >	Hmm, didn't see my simily did you?  Oh well...
 >	>snip<
 >: In your if statement, the else clause gets executed if *any one* of the
 >: test expressions fails! ``if (1 && 1 && 0)'' will launch into the *else* clause.
 >: In MY if statement, the else clause only gets executed it the *outermost* test
 >: condition fails. ``if (1) if (1) if (0) statement 1; else statement2;'' will
 >: cause *neither* statement1 *nor* statement2 to be executed!
 >	There are ways around this as well, however simply taking the 10
 >	secs of time to add the }{s as your past example did would be the
 >	easyest way in Perl.
 >
 >: See, the two are not equivalent at all!
 >	You're right, and that teaches me to followup after a double
 >	espresso. ;-}

Same with me: a dangling else in C is taken to be the innermost case, not the
outermost. In LR parser lingo, it is resolved by doing a shift, not a reduce,
which causes the innermost else clause to be ``stacked'' with the nearest
matching if. This is the most common resolution of the ambiguity. The yacc
parser generator reflects this thinking---in the case of a shift/reduce
ambiguity in the grammar, it emits a warning, and generates a parser that will
do the shift.

Thus my bracketing of the original C program was as incorrect as your attempt
to make an equivalent single if using the and operator. 

Make that two double espressos.
-- 
I'm not really a jerk, but I play one on Usenet.