Re: and then... (a curiosity)

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 3 Sep 2008 15:14:15 +0200, stefan-lucks@see-the.signature wrote:

>>> A short-circuit "and" (instead of "and then") would not remove that choice
>>> -- see the "much better style" above.
>> 
>> But it would break the mathematical purity of "and".
> 
> Well, if "False and F(X)" is allowed to raise an exception, this is even 
> worse (more far away from mathematical purity) than if "False and F(X)" is 
> just false -- whatever F(X) would do.

Well, it depends. Consider:

   function F (...) return Boolean; -- May raise Some_Error exception

This breaks the contract that promises a *Boolean* result. Mathematically
it means that the result is not Boolean but a value from some other type
Boolean_Ex is (False, True, Some_Error_Fired). Here Some_Error_Fired is an
ideal "value" of Some_Error being propagated. But then "and" is also broken
in its arguments and the result. In particular for "and" defined on
Boolean_Ex and returning Boolean_Ex, the theorem

   False and X <=> X

does not hold anymore. Therefore it cannot be implied. A similar logic
applies to side effects. You just do the Cartesian product of the effect
and the written set of values. This becomes the "true" set of values.

As somebody already pointed out. People using "and" on arguments with side
effects, are fooling themselves and those who are to read the program.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de