Re: and then... (a curiosity)

["Karel Th�nissen" <thoenissen@garabit.nl>]

> On Thu, 4 Sep 2008, stefan-lucks@see-the.signature wrote:
>
>> On Thu, 4 Sep 2008,  wrote:
>> > So if I understand you correctly this time, the raising (or not) of an
>> > exception for "if Y/X<000" should in your view depend on the context
>> > where
>> > it is used: [...]
>>
>> No, you misread me again. If you had read some earlier posts from me in
>> this thread, what I am trying to express is that "and" should better do
>> what "and then" actually does. That is it, so simple!

If that /were the only thing you wrote/, then it would indeed be simple. But
in your earlier posting, /and/ a few lines down in the very post I am
replying to now (as a quote from an earlier posting), you write something
different. See few lines further down.

I personally could life with the idea that in Ada, 'and' would have had
conditional formantics (now  and-then)and some other operator would have
unconditional formantics (now and). That is just swapping tokens at the
lexical level. Fine. What is your point?

> To be precise, here is a cut-and-paste from what I wrote in another
> posting:
>
> 1. If the A- or the B-part in "if A and B" raises an exception, but the
>   other part is false, the "right thing" (TM) to do would be to transfer
>   control to the else clause (or below "end if", when there is no else).
>   The intermediate result can be viewed as a three-valued logic
>   expression, but the final outcome of the Boolean expression must be
>   Boolean, of course.

Thank you, there it is.

Contrary to what you write above, this is /not/ the formantics of and-then
in Ada. In Ada, the conditional boolean operators are not symmetric: "A
and-then B" is not equivalent to "A and-then B". So you are proposing
something new in the language beyond the mere choice of lexemes.

The formantics you propose would be an exception handler that does not
discriminate neither for the type of the exception, nor for the side of the
operator where it was raised. The ambiguity of both sides raising an
exception is handled by rule 2 below.

The formantics you propose would execute the else-branch for *any*
exception, not just the divide by zero in the example, but also overflows
and Gods knows what else. A nice place for bugs to hide. It is even worse
than that: if there is no else-branch, then the execution silently continues
after the end-if. Great. Bugs now go completely undetected. The worst
possible thing you could do for high-integrity software.

> 2. If both raise A and B an exception, of if one raises an exception and
>   the other one is true, an exception is propagated.

Why not follow your own logic and really use a three-valued logic and
introduce a three-branched if-then-else structure with a third branch for
handling "undefined and undefined" or whatever you call it.

> 3. I would be willing to pragmatically sacrifice mathematical purity for a
>   shortcut rule: If A is false, the expression is false, whatever B does.
>   If A raises an exception, of if A is true and B raises an exception,
>   the exception is propagated.

Congratulations, you just reinvented the and-then in Ada.

> 1. and 2. describe some "ideal" behaviour, but 3. describes what the one
> can realistically expect from the compiler. BTW, the compiler would not
> need to be that incredibly smart. If an exception is raised when
> evaluating a Boolean expression, the exception could be handled inernally,
> to finish evaluating the Boolean expression, and re-raised if neccessary.

1+2 may appear ideal for a mathematician, because of the symmetry it
provides. But we are not doing mathematics. I am a professional software
engineer and I do not want my stupid mistakes, that I do make, caught by
contracts that raise all sorts of violations (program exceptions), go
unnoticed because the exception is silently handled in the else-branche or
not at all if there is no such branche.

Ideal behavior is a fata morgana from lala-land. We have to deal with
fallible developers and machinery.

> ------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
>               Stefan dot Lucks at uni minus weimar dot de
> ------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------