and then... (a curiosity)

> if A(X) and B(Y) then ... end if;
>
> IMHO, much better style is the following:
>
> declare
> Tmp_A: Boolean := A(X);
> Tmp_B: Boolean := B(X);

Tmp_B: Boolean := B(Y) -- sorry for the typo!

> begin
> if Tmp_A and Tmp_B then ... end if;
> end;

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

On Aug 30, 2:28 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 29 Sie, 23:47, Samuel Tardieu <s...@rfc1149.net> wrote:
>
> > Sometimes, you want to ensure that both sides of the boolean operator
> > have been evaluated. Here is an example:
>
> > -- Send the message to the log and return True if it
> > -- has been logged at least at one place succesfully.
>
> > function Log (Message : String) return Boolean is
> > begin
> > return Log_To_Network (Message) or Log_To_Disk (Message);
> > end Log;
>
> This is actually a bad example. It might use "or else" and still
> retain the semantics as described in the comment above.

I don't think the example is bad at all, but the comment might be
ambiguous. I understood Samuel's point to be that the function logs
to the network if possible, and it logs to disk if possible---ideally
it should log to both places, but we're hoping it logs to at least
one. If you use "or else" it will never log to both. That apparently
isn't what is desired.

-- Adam

On Sep 1, 11:53 pm, Martin Krischik <krisc...@users.sourceforge.net>
wrote:

> > My problem is not with the theoretical elegance as such, but rather that "or"
> > vs "or else" is not immediately clear to me.
> > As a multi-language programmer, I am really really used to thinking of boolean
> > or as "if one is true we don't care about the other".
>
> Funny I am not - probably because my first languages where Basic and
> Pascal - and Basic and Pascal do not guarantee short cut boolean. Modern
> Basic and Pascal dialects might have it but it is not guaranteed in the
> language itself.

Yeah, and I don't think COBOL or Fortran guarantee "or else" semantics
either. I was happy when I first started working in Ada because it
had this. C has this feature, although like everything else in the
language it was represented in proto-Egyptian hieroglyphics rather
than in English, but this was a new and exciting feature to me. I
guess Ray must be a young'un who only learned all them durn newfangled
languages and never had to struggle with REEL languages like us
dinosaur REEL programmers did back when we had to put all our programs
on punch cards and then lug them five miles through the snow to the
computer operator, uphill both ways.....

-- Adam

On Aug 30, 8:35 am, "Peter C. Chapin" <pcc482...@gmail.com> wrote:
> Dmitry A. Kazakov wrote:
> > I am unsure if the arguments of "and" are eager. You are a language lawyer,
> > I am not. But I used to think that the eagerness of evaluation is rather
> > unspecified, so that the compiler is free "not to care," when it optimizes
> > the code, as Jeff Carter has pointed out.
>
> I thought all function arguments must be evaluated, but that it is
> unspecified in which order this evaluation is done.

Correct. If an argument to a subprogram contains another function
call that has side-effects, that argument must be evaluated, and the
compiler is generating incorrect code if it doesn't (which is *not*
the case with "or else"). I think that if the compiler can determine
that the only possible side effect would be to raise a predefined
exception, the compiler doesn't have to actually do any evaluation---
the code isn't required to perform computations just for the sake of
doing the computations. I'm not sure how far the predefined-exception
thing goes, though. If you say

if X = null or X.ID < 0 then ... -- "or", not "or else"!

even though the right side is supposed to be evaluated, I suppose that
a compiler could in theory generate code that doesn't bother to
evaluate it if X is null, because there would be no point to reading
that field (assuming no memory-mapped I/O is involved here!!). I
think that behavior is allowed by the Implementation Permissions in
11.6, but of course it would be quite foolish to write code like this
and rely on the optimization.

-- Adam

Martin Krischik <krischik@users.sourceforge.net> writes:
> When I was at Polytechnic first language was PL/1, second Pascal and
> therefore methodology was different. i.E. Don't rely on the execution
> order of boolean expressing.

This I also agree with, although I admit being used to the short circuit &&
forms in the C-like languages.

But my point is about having the source code be clearer when both operands are
required to be evaluated, especially when this is a possibility:

> They are not necessarily both executed with plain old OR and AND either.
> Plain old OR and AND leaves all options open to the optimizer: Out of
> order execution Common subexpression elimination or dead code elimination.


--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul.

Adam Beneschan <adam@irvine.com> writes:
> I guess Ray must be a young'un who only learned all them durn newfangled
> languages and never had to struggle with REEL languages like us dinosaur
> REEL programmers did back when we had to put all our programs on punch cards
> and then lug them five miles through the snow to the computer operator,
> uphill both ways.....

Missed the punchcards, fortunately, although I was forced to suffer the use of
paper-only terminals in my first few years of comp sci.

--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul.

On Tue, 2 Sep 2008 15:32:40 +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.

Disagree.

I think a far better idea would be to introduce pure functions and
procedures with results. Functions with side effects and access parameters
is an insanity.

It is also worth to consider introduction of commutative, associative,
inverse operations per contract. This would allow the compiler to prevent a
procedure with the result from appearing in a commutative "and". The
evaluation order of non-associative etc operations could be fixed.

Later it would also allow to manage a combinatory explosion variants in
multi-methods ("and", "or", "+", "*" etc).

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

stefan-lucks@see-the.signature writes:
[...]
> Well, if the program requirements are that the side effects for A and B
> actually occur, I consider it poor programming style if people just write
>
> if A(X) and B(Y) then ... end if;
>
> IMHO, much better style is the following:
>
> declare
> Tmp_A: Boolean := A(X);
> Tmp_B: Boolean := B(X);
> begin
> if Tmp_A and Tmp_B then ... end if;
> end;
>
> This makes the programmers intention clear, "if A(X) and B(X)" doesn't.
[...]

(As you said in a later followup, you meant B(Y) rather than B(X).)

I disagree. The shorter form

if A(X) and B(Y) then ... end if;

makes the programmer's intent absolutely clear to anyone who knows
what "and" means in Ada. If I saw the other version my first thought
would be to wonder why the programmer didn't just write "if A(X) and
B(Y)". After a moment's thought, I'd assume that the order of
evaluation of A(X) and B(Y) is significant. It would never occur to
me that the long form was used to ensure that both A(X) and B(Y) are
evaluated, since the "and" operator already does that.

All programming languages have their quirks, and none of them exactly
follow mathematical notation (in part because there is no single
mathematical notation). If you try to write code that will be
understandable to someone who doesn't know the language, you'll end up
with an overly verbose mess that can hardly be understood by someone
who *does* know the language.

If I were doing the equivalent of the above in C, whose logical "and"
operator "&&" does do short-circuit evaluation, I probably would
declare the two temporaries. In Ada, it's just not necessary.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

stefan-lucks@see-the.signature schrieb:

> IMHO, much better style is the following:
>
> declare
> Tmp_A: Boolean := A(X);
> Tmp_B: Boolean := B(X);
> begin
> if Tmp_A and Tmp_B then ... end if;
> end;
>
> This makes the programmers intention clear, "if A(X) and B(X)" doesn't.
>

>
> But do you really dispute that following the mathematical conventions
> as much as possible would improve readability?

I agree with all of the above. However, after having seen much suffering
from what people think are mathematical conventions used in programs,
I think mathematical conventions should be verboten.

Mathematical conventions are, unfortunately, *much* too vague
to be good guidance. Most of the time they don't apply
in computer programs. On the contrary, digital computers started
their lives for exactly this reason: mathematics had
no formalized steps and finite sets of numbers were uncommon.

Mathematical assumptions make us think that Integer is an integer,
which it isn't! As you have explained, there is no _|_ in the
set of mathematical integers.

A mathematics for computer programs would be different.
Not like "high school operators" between "high school numbers".


--
Georg Bauhaus
Y A Time Drain http://www.9toX.de

Ludovic Brenta schrieb:
>> But do you really dispute that following the mathematical conventions
>> as much as possible would improve readability?
>
> Of course not. That's wgy "and" should have its mathematical meaning -
> i.e it should not impose an order of evaluation and it should not
> avoid evaluating its operands. That's what "and then" is for.

There is no order, but still the trouble is that mathematics
is not usually about evaluation at all. The process of
evaluating is not explicitly present in the mathematical
meaning of "and". It does not build on "process" or "procedure".

*

Another issue with "and then" short-circuits apparears
in some "elsif"s:

if This_Thing and then Another_Thing then

elsif This_Thing and then Yet_Another_Thing then

.... more of the same ...

else
-- this catches, errhhm, how many of which of
-- the alternatives and when?
end if


Nest instead and an "unambiguous if-then-else statement"
removes the need of low-level source code optimization
such as too many short-circuits. Makes your fuses blow

--
Georg Bauhaus
Y A Time Drain http://www.9toX.de