Re: and then... (a curiosity)

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

<stefan-lucks@see-the.signature> schreef in bericht 
news:Pine.LNX.4.64.0809041404570.22581@medsec1.medien.uni-weimar.de...

>> > Thus, "if X/=0 and Y/X<100" should go into the else-branch, instead of
>> > raising an exception.
>> > The shortcut version "if X/=0 and then Y/X<100" does exactly the right
>> > thing.

>> That would be a very bad idea. With that in place, an exception raised by 
>> a
>> simple programming error, /any/ programming error, would give control to 
>> the
>> else-branch.

> You misread what I wrote. A statement such as "if Y/X<000" should
> definitively propagate an exception for X=0, and I never said anything
> otherwise.

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: /do not raise/ inside branching conditions of a certain pattern, 
but /do raise/ when used as an ordinary statement. I fear that you 
underestimate the complexities of putting that smartness in a compiler and 
you overestimate the abilities of the ordinary programmers to understand 
what is going on.

No, I do not think I misread. Your writing was not precise: you wrote

   "if X/=0 and Y/X<100" should go into the else-branch, instead of raising 
an exception.

But in Ada it does not go to the else-branche for X=0. So you are proposing 
a language change, and I point out that that would be a vey bad idea.

We cannot expect the compiler to be so smart to distinguish exceptions that 
are avoidable if the left operand had been evaluated first (as with 
conditional boolean operators) from the other exceptions in general. So the 
only viable options are: not doing it like this at all (my choice) or 
picking the else branche for all exceptions. That would make it in invisible 
exception handler. Bad, bad, bad. And as noted above, it would also 
introduce context sensitivity whether exceptions should be raised or not. 
Again very bad.

And if you do want conditional evaluation, you choose 'and then'. What is 
wrong with it? Okay, it is wordy, but the formantics in Ada are very 
precise. That is more important than 5 characters saved.

Maybe you meant 'and' in your example in a more abstract sense without 
providing the precision is demanded by Ada. Unfortunately, you expressed it 
as valid Ada.

> But when "if X/=0 and Y/X<100" propagates an exception for X=0, as, alas,
> done in Ada, something is logically wrong.

So you do think that it should not raise an exception and go to the 
else-branche????? Now what do you want? You contradict yourself. Or this the 
reason you came up with the context dependent interpretation of source code? 
The problem is probably that you use the words 'and' and 'should' in two 
different ways. Seems to be the whole point of this discussion.

How much intelligence do you expect from a compiler? And even if the 
compiler where that smart, would we mere programmers understand what was 
going on. How smart should the compiler be? Should it also start using 
inference, perhaps using whole program analysis?

Computing just is not standard logic. Simple boolean logic will not help us 
out and we should stop looking at mathematics and logic as the holy grail in 
computing. It is a different subject.

> BTW, why do you think that an exception, such as a Constraint_Error,
> should logically count as a contradiction?
>
> Dividing something by zero is undefined, not a contradiction.

That again shows my point that mathematics and computing are two different 
beasts. A mathematician will put the pencil done and stop immediately when 
asked to do an undefined operation, such as a division by zero. That just is 
not an option if you are flying 1000 km/h. Then you raise an exception and 
try to make the best of it, probably working from an unknown or even 
corrupted state, regaining control over the machine and bringing the 
passengers to safety.

If the mathematician were to continue anyway and tried to find his way out 
like our software, he could easily obtain contradicitonary results. This 
should be compared with invariants that are broken because of the reaching 
of an undefined operation/ raising an exception in software.

Comparing undefined/raising an exception allowed because they share the 
property: that the result is neither true nor false:

   false AND raisingAnException => raisingAnException
   false AND contradictionary      => contradictionary

Remember that I introduced this point about contradictions where someone 
(you?) equated ternary logic with Kleene's logic. There are other ternary 
logics.

Just to be nitpicking: coming from a DbC-background, a division by zero 
should raise a *violation* of contract, not an exception. A violation indeed 
is a contraction with the explicitly stated contracts. After a violation 
anything goes.

*Exceptions* should be used for things that can be expected, but that should 
be very rare and that are to hard to handle using standard control 
structures. Think of printers that break down, or network failures.

Groeten, Karel