🚀 go-pugleaf

In article <4jq1fe$a48@solutions.solon.com>,
Lawrence Kirby  <fred@genesis.demon.co.uk> wrote:
 >In article <4ja3pu$p8r@solutions.solon.com>
 >           bcalbridge@dcccd.edu "Bob Calbridge" writes:
 >
 >>I'm currently taking a C++ class in order to teach it next Fall.
 >>I've taught C programming for the last three years so I know a bit
 >>more than some of the people who program in it that they bring in to
 >>teach it.   The class I'm in got into a discussion that I, as a fellow
 >>"student" had a hard time explaining to the class.
 >>
 >>The issue revolves around an if statement with a predicate that may
 >>look like the following:
 >>
 >>    if (value || ( GetState (value) && dumb == !smart)) {.....
 >
 >Those other explanations looked rather complex and involved (well at least
 >to me!) ;-)
 >
 >In the example expression || has 2 operands:
 >
 > LHS:  value
 >
 > RHS:  ( GetState (value) && dumb == !smart))
 >
 >|| evaluates its RHS only if the LHS evaluates to zero.
 >
 >>The instructor agrees with me, as I'm sure everyone else here would,
 >>that if value evaluates to true the function GetState() will never
 >>execute due to short circuiting of the logical operators.
 >
 >Right, except that it is the whole sub-expression that forms the RHS operand
 >that is short-circuited.

I think that the whole problem here is a confusion between parsing (syntax) and
valuation order (semantics), which can be ``decoupled''.

The evaluation order in this case is partly bottom-up (the values are
synthesized starting from leaf nodes, working their way up), but partly
dictated by semantics that work top-down.

If you allow, I will write a piece of pseudo code to simulate:

function eval (tree T) : integer
	if T.operator = '||' then
		if (!eval(T.left)) then
			return eval(T.right)
		else
			return TRUE;
		endif
	elsif T.operator = '*' then
		return eval(T.right) * eval(T.left);
	endif