"?:", "a and b or c" or "iif"

[Fred L. Drake]

Michael Vanier writes:
 > This sounds like another job for bytecodehacks :-)  

  The bytecode could certainly support such a construct, but ...

 > I personally detest the ?: operator in C, mainly because people who use it
 > tend to write fun code like this:
 > 
 > a = (b ? (c ? d : (e ? f : g)) : (h ? i : j));

  *I* never wrote this!  1-)  I agree, this is unreadable, but that's
not a good reason not to provide a facility to allow something
semantically equivalent as an expression.

 > If something like this is coded, I *strongly* recommend that it not be an
 > operator but something like an "iif"-type function.  Of course, to do that,
 > you need to be able to define functions with lazy evaluation.  THAT

  By pushing the "laziness" to the function implementing the
operation, the cost of function calls would increase, possibly
substantially.  While this would be nice, the fact that an arbitrary
callable might require either agressive or lazy evaluations of
arguments (or both!) would mean that using bytecode to implement an ?: 
equivalent is out of the order (if a function is used for that
purpose.  It also means that the "laziness" or "agression" of an
expression's evaluation is not evident at the call site.  I think
*this* would be a huge mistake.  (Hmm.. it also means that the called
function could have side-effects that changes the values of the lazily 
evaluated expressions, as well -- it's looking worse & worse!)
  I think it really needs to be a syntactic construct to avoid the
problems I've identified; with syntax, the laziness of an expression
is explicit.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives