For review: PEP 308 - If-then-else expression

[Paul Rubin]

"James P. Rutledge" <jrut at spamcop.net> writes:
> It *might* be possible to obtain the effects of the proposed expression
> in a more general way by extending the semantics of the following
> existing construct:
> 
>    ("html", "text")[is_html(msg)]
> 
> The above expression provides the string "html" or "text" depending upon
> the return value of the function "is_html".
> 
> If a special case were to be recognized by the parser, that of a tuple
> "literal" followed immediately by an index selector, then only the tuple
> item selected by the calculation of the index would need to be actually
> calculated (a form of "lazy evaluation") as in the following example:

Argggh!!!!!!   That's unbelievably bizarre.

Since Algol-60 came up in this discussion before, maybe lazy
evaluation can be accomplished with some explicitly-requested
form of call-by-name parameter passing to functions.  For example,

   f@(exp1, exp2, exp3)

could be a shortcut for saying

   f(lambda: exp1, lambda: exp2, lambda: exp3)

Then the cond function could be written

   def cond(e, x, y):
      if e(): return x()
      else: return y()

another possible notation could be a leading dot to thunkify an expression:
.expression would be the same as (lambda: expression).  So you could
write

    def cond (e, x, y):
      if e: return x()
      else return y()

and call:

    cond(e, .exp1, .exp2)

Example:

    abs_x = cond(x >= 0, .x, . (-x))

Improvements on the above are surely possible.