and then... (a curiosity)

Dear.all,
today while I was writing in my favorite language
(PERL with C extensions, of course :-)))) I wondered why in Ada the
"shortcut and" is "and then", while the simple "and" has not
a shortcut behaviour. My curiosity stems from the fact that
I am not able to envision any situation where the "non shortcut"
version would preferable, but I immagine that there was some
reason for this choice. Do anyone have any hint?

Thank you in advance.

> I wondered why in Ada the "shortcut and" is "and then", while the
> simple "and" has not a shortcut behaviour. My curiosity stems from
> the fact that I am not able to envision any situation where the "non
> shortcut" version would preferable, but I immagine that there was
> some reason for this choice. Do anyone have any hint?

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;

Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

On Aug 29, 2:06 pm, mockturtle <framefri...@gmail.com> wrote:
> Dear.all,
> today while I was writing in my favorite language
> (PERL with C extensions, of course :-)))) I wondered why in Ada the
> "shortcut and" is "and then", while the simple "and" has not
> a shortcut behaviour. My curiosity stems from the fact that
> I am not able to envision any situation where the "non shortcut"
> version would preferable, but I immagine that there was some
> reason for this choice. Do anyone have any hint?

Aside from Samuel's comment (sometimes you want both sides evaluated),
there are some very important differences. "and" is a predefined
function and can be used wherever a function can (you can rename it,
pass it as parameter for a generic formal function, etc.). Besides
the "and" on Booleans, there are predefined "and" functions on arrays
of Booleans and on modular types [both of those do bitwise AND's].
You can define your own "and" on other types if you like. Like every
other function, the use of "and" requires that all (both) of its
arguments be evaluated. The language also defines "or", "xor", and
"not" with similar properties.

"and then" is not a function, however, and has none of these
properties.

To make "and" [and "or"] on two Booleans behave like the short-circuit
form would introduce a major inconsistency into the language.

-- Adam

Adam Beneschan wrote:
>
> "and then" is not a function, however, and has none of these
> properties.
>
> To make "and" [and "or"] on two Booleans behave like the short-circuit
> form would introduce a major inconsistency into the language.

In addition to the other reasons, there's the question of processor
optimization. Although we have a sequential view of how code is executed, modern
processors do all sorts of strange optimizations, such as speculative execution,
that violate that sequential view. It's my understanding that the short-circuit
forms can prevent such optimizations. Apparently, code that may evaluate only
one of the 2 expressions can actually be slower than code that must evaluate both.

--
Jeff Carter
"If I could find a sheriff who so offends the citizens of Rock
Ridge that his very appearance would drive them out of town ...
but where would I find such a man? Why am I asking you?"
Blazing Saddles
37

On Fri, 29 Aug 2008 15:28:16 -0700 (PDT), Adam Beneschan wrote:

> "and then" is not a function, however, and has none of these
> properties.

It could be made a function if Ada had lazy arguments.

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.

So basically, provided the above is correct, the choice was motivated by
least strong precondition (=unspecified eagerness), rather than by choosing
between eager and lazy evaluation.

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

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.

Peter

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.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Maciej Sobczak 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.

"At least one" of the logs should, I guess, mean to try both.
I.e., the Log subprogram is not about its return value alone.
"Or" achieves all of that (the semantics).

"Or else" might also establish a strict preference for the
network log. "Or" should not.

Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de> writes:
> Maciej Sobczak 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.
>
> "At least one" of the logs should, I guess, mean to try both.
> I.e., the Log subprogram is not about its return value alone.
> "Or" achieves all of that (the semantics).
>
> "Or else" might also establish a strict preference for the
> network log. "Or" should not.

This kind of confusion makes me prefer an unambiguous if-then-else statement.

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

Maciej Sobczak schrieb:
> 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.

Actually it is good example - for both:

1) Log to both Disk and Network and return true if at least one was
successful:

Log_To_Network (Message) or Log_To_Disk (Message)

2) Log to Network and if that fails log to Disk and return true if at
least one was successful:

Log_To_Network (Message) or else Log_To_Disk (Message)

And it shows nicely the why there are two: The programmer can decide
which behaviour he / she wants.

Martin

--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com