Re: and then... (a curiosity)

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6528 bytes --]

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

>> 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!

Refuted in another reply.

>> 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.
>
> Very strange that the Ada compiler is able to compile stuff if you write
> "and then" instead of "and". Following your point, the designers of Ada
> did overestimate the smartness of compilers. ;-)

My objections are targeted at the thing that you propose (elsewhere called
1+2). That beast would either allow bugs to hide, or would require whole
program analysis and perhaps mind-reading capabilties.

> Now really, the whole thing seems to work quite well for "and then". And
> in quite a few languages other than Ada for "and".

If course it works. It is a different thing thing you propose.

>> 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.
>
> I am not trying to propose to change Ada -- regrettably this would break
> compatibility too much. But if it where not for compatibility reasons, I
> would consider to propose that change.

>> 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.
>
> Strange that the compiler is smart enough to do the right thing if we just
> write "and then" instead of "and". ;-)

You still seem to think that the conditional-and in a programming language
can be symmetric.

>> 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.
>
> Where is the context sensitivity about exceptions when you write "and
> then"?

There is no need in Ada, for the simple reason that the compiler can see the
difference between "A and B" and "A and then B" without knowing anything at
all about the context in which it is used. Therefore, the choice of
formantics is known while parsing that particular expression/ production in
the grammar.

>> 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.
>
> I could not care less about the five characters.
>
> But the designers of Ada (and the designers of almost any other language
> out there) have chosen the identifier "and" for a reason. And the reason
> is that the language "and" actually attempts to mimic the mathematical
> "and".

Yes, I agree and that is very unfortunate. But while we are at it. The
'designers' of logic made the same mistake: they have chosen an
interpretation that difference from the word "and" in English. Take a
semiologist to explain the difference. The important thing is that the
formantics of the operator be well-defined. That is the case in the various
logics as is the case in Ada (but not in most other programming languages).

>> 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.
>
> No, I simply complained about a (minor) design flaw of 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.
>
> Are you trolling? That quote of mine is a repetition, not 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.
>
> Agreed!
>
> But in a lot of mathematical papers, descriptions of algorithms and the
> like, you actually find expressions like "X/=0 and Y/X<1000". Such an
> expression does have a well-defined meaning, even for X=0. Nobody would
> drop his or here pencil.
>
> BTW, even the order is an issue -- if you write "Y/X<1000 and X/=0" in a
> mathematical paper, that would be logically correct, but you could bet on
> the reviewers asking you to rewrite it to "X/=0 and Y/X<1000".

Then the author is not using boolean Algebra, but some three valued logic.
Quite possible. Perhaps a logic with:

   false and undefined  <=> undefined and false <=> false

If that is the definition, then that would be possible. But this is not the
na�ve definition from Boolean algebra. This definition must be learned, but
then you could equally well learn both well-defined definitions as from Ada.

But you may still prefer above definition from a three-valued logic. I
agree, the logic is well-defined and mathemtically elegant. However, it is
an engineering disaster. We write millions of lines of code and we must deal
with violations, exceptions, and validations errors. In general exceptions
are a fact of life in computing. And I do not want my exceptions
(violations, errors) to get uncaught because of some interpretation of
boolean operators that sends them to else clause or silently resumes
execution, no matter how elegant the notation for completely correct
programs.

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