1. Short-circuit evaluation
- Posted by rforno at tutopia.com Aug 09, 2002
- 405 views
Rob: I know, it is seldom used and impractical, but have you thought about extending short-circuit evaluation to the operations I mention below? I was thinking about this only regarding educational purposes: you know there are 16 possible binary Boolean operations with 2 operands. Some comparison operations can be used in a Boolean context. For example, XOR is not needed at the variable-level because it may be substituted by !=. The operations I was thinking of are: if (a > b) >= (x = z) then ... If a > b is true, then there is no need to evaluate x = z. if (c <= u) > ( d > g) then... If c <= u is false, then there is no need to evaluate d > g and similarly with <= and <. These operations, when used with Boolean operands, might be thought about as "implication", etc. = and != cannot be short-circuited. AFAIK, C doesn't use this little trick. Regards.
2. Re: Short-circuit evaluation
- Posted by Robert Craig <rds at RapidEuphoria.com> Aug 10, 2002
- 400 views
Ricardo Forno writes: > if (a > b) >= (x = z) then ... If a > b is true, then there is no need to > evaluate x = z. True, but I don't think I've ever seen an expression like that used in a real program. Short-circuiting can only theoretically be performed in Euphoria when an expression must produce an atom as a result. So we know that: true or expression is true (without evaluating expression) false and expression is false (without evaluating expression) If expression might yield a sequence, we can't short-circuit. Short-circuit evaluation could be extended into new areas. For example, the expression returned from a type... type one_item(object x) return atom(x) or length(x) = 1 end type Right now, length(x) will fail if x is an atom. With short circuiting, this expression would be ok, and we can assume that a type must return an atom. Other cases would include expressions that are assigned to a variable (or parameter) declared as an atom. However, people need to remember, preferably without consulting the manual, which expressions can be short-circuited and which can't. I don't want to create a huge section in the manual, filled with if's, and's and but's, that tries to explain when short circuit evaluation will be used. Right now, and/or short circuiting happens for control-flow statements -if/elsif/while. In practice, that covers most of the useful situations. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com