PEP308 - preference for 'x if c else y' over 'c then x else y'

[Andrew Koenig]

jcm> Your claim was that side effects don't enter into the picture (I
jcm> disagree).  Saying "your program is incorrect" doesn't tell me
jcm> enough.

Actually, it does.

What I'm thinking of is languages such as Haskell that are totally
side-effect free.  The question, then, is what happens if one writes
a program in such a language that divides by zero, just to pick one
example.

The answer, as I understand it, is that the program terminates with
a diagnostic message saying that the program could not be executed
normally because it attempted to divide by zero.  In particular, there
is no mechanism in the language to intercept that error condition
and produce a different result, because such a mechanism would
introduce side effects.

So the next question is:  What should a programmer do who wants to detect
such an error condition?  My understanding is that Haskell offers a
number of library functions with behavior analogous to the following:

        def divide(num, denom, fail, succ):
            if denom == 0:
                return fail(num)
            else
                return succ(num/denom)

So the idea is that you specify in advance the computation that you
wish to take place if the division is successful or unsuccessful, and
the library function takes care of evaluating the appropriate one.

Side effects are therefore avoided.

-- 
Andrew Koenig, ark at research.att.com, http://www.research.att.com/info/ark