Short circuit boolean evaluation

Short circuit boolean evaluation

[svaa]

Hello

I'm a newbie in Ada, I've worked in several languages, last three
years I've worked in Delphi (Pascal).

Shouldn't be a good idea to implement short circuit evaluation for
boolean expresions as default in Ada0x?

Currently Ada uses "and then" and "or else" to implement short
circuit. I think it's a burden. The default behavior of "and" and "or"
should be "and then" and "or else".

The questions are: When is useful short circuit evaluation? when is
useful full evaluation?

Short circuit evaluation:
sometimes it saves you of spliting "if sentence" for previous checks:
if (a/=0) and (b/a>k) ... (A quite common event when you chek null
pointers).
sometimes allows you to decide the order according with you human
knowledge of probability of each expression.

full evaluation:
Let the compiler freedom to optimize the order?

In fact, I usually have a clear idea of the order I want the
evaluation. Perhaps there are a few cases of simple expresions where I
don't mind the order, and I can't guess, at first sight, which has
better performance. Probably I can optimize a boolean expresion better
than a compiler. I know what's the program about!!.

Standard pascal has full evaluation, but most compilers have an option
for short circuit evaluation, and it's the default one, that should
give a clue. In years of programming I'have never missed the full
evaluation, but in some languages that don't use short circuit, I've
missed it. As in aritmetic expresions, I'm aware of left to right
boolean evaluations, I take advantage of it, and I say ****!!,
whenever I have to write "then" after "and" and "else" after "or".

Programs will have the same result if you change the behavior to short
circuit, but you will save a lot of "then" and "else".

Well, I'm missing the case of expresions that call functions. If that
function have side efects, you have to evaluate it. I think this is a
bad coding style, but perhaps it's because I usually work with
short-circuit. In this cases you would lose backward compatibility.
Although it could be solved with a pragma.

Anyhow, I think that even without backward compatibility, the advanges
of short circuit evaluation are worth.

But if someone can't live with of full evaluation you could add the
operators "or always" and "and always", I'm sure they will be less
used than "or else" and "and then" ;-)

Re: Short circuit boolean evaluation

[Steve]

If you look in the history of this newsgroup on google, you'll find that
this subject has already been discussed extensively.

I consider it unimaginable to make such a fundamental change to a language
in order to save a few keystrokes when more than a few billion lines of
source code might be effected.

Steve
(The Duck)


"svaa" <svaa@ciberpiula.net> wrote in message
news:87f5a614.0311051528.30450c7a@posting.google.com...
[snip]
>
> Anyhow, I think that even without backward compatibility, the advanges
> of short circuit evaluation are worth.
>
> But if someone can't live with of full evaluation you could add the
> operators "or always" and "and always", I'm sure they will be less
> used than "or else" and "and then" ;-)

Re: Short circuit boolean evaluation

[svaa]

"Steve" <nospam_steved94@comcast.net> wrote in message news:<Vwjqb.115053$HS4.999172@attbi_s01>...
> I consider it unimaginable to make such a fundamental change to a language
> in order to save a few keystrokes when more than a few billion lines of
> source code might be effected.

I wouldn't call it a few  keystrokes, I use it in every condition. 

Anyhow, that's not the problem, the problem is that short-circuit has
clearly proved to be better, I supose that the idea of Ada0x is to add
new features and remove flaws. Backward compatibility is a problem,
but it could be resolved with pragmas etc. Most sofware have eventualy
made changes that had backward compatibility problems. Probably a big
problem with backward compatibility means a big improvent for future
developments.

Sure we can live with full evaluation, but we can live better with
short circuit. If we accept that short circuit is better than full
evaluation, the change must be done, sooner or later. This time is as
good or bad as any another.

Perhaps Ada0x could let the full evaluation as default, but add a
pragma that allows short circuit, and in ada1x make it as default. (it
doesn't means make illegal "and then" operator). Ada has fame of
bloated and burden syntax, things like this doesn't help. I think it
is time and make good changes, even if they are deep. It's not time to
be conservative, but brave.

Will we carry "and then" in ada5x? Will we accept that flaw (a minor
flaw, but a flaw) in the first version must remain for ever?.

Re: Short circuit boolean evaluation

[tmoran]

> short-circuit has clearly proved to be better
Says who?  I claim short-circuit is clearly worse.  Do you have any
evidence otherwise?

Re: Short circuit boolean evaluation

[Mark Lorenzen]

svaa@ciberpiula.net (svaa) writes:

> "Steve" <nospam_steved94@comcast.net> wrote in message news:<Vwjqb.115053$HS4.999172@attbi_s01>...
>> I consider it unimaginable to make such a fundamental change to a language
>> in order to save a few keystrokes when more than a few billion lines of
>> source code might be effected.
>
> I wouldn't call it a few  keystrokes, I use it in every condition. 
>
> Anyhow, that's not the problem, the problem is that short-circuit has
> clearly proved to be better, I supose that the idea of Ada0x is to add
> new features and remove flaws. Backward compatibility is a problem,
> but it could be resolved with pragmas etc. Most sofware have eventualy
> made changes that had backward compatibility problems. Probably a big
> problem with backward compatibility means a big improvent for future
> developments.

Has clearly proved to be better? Where do you get that idea from?

>
> Sure we can live with full evaluation, but we can live better with
> short circuit. If we accept that short circuit is better than full
> evaluation, the change must be done, sooner or later. This time is as
> good or bad as any another.

Why should we accept that?

>
> Perhaps Ada0x could let the full evaluation as default, but add a
> pragma that allows short circuit, and in ada1x make it as default. (it
> doesn't means make illegal "and then" operator). Ada has fame of
> bloated and burden syntax, things like this doesn't help. I think it
> is time and make good changes, even if they are deep. It's not time to
> be conservative, but brave.
>
> Will we carry "and then" in ada5x? Will we accept that flaw (a minor
> flaw, but a flaw) in the first version must remain for ever?.

Why is it that every time someone complaints about the difference
between Ada and other languages, that it is Ada that is flawed?

Please explain why you want to use:

if (Alarm_Is_On and then Operator_Is_Alerted) then
  Wait_For_Operator;
else
  Call_Fire_Brigade;
end if;

instead of:

if (Alarm_Is_On and Operator_Is_Alerted) then
  Wait_For_Operator;
else
  Call_Fire_Brigade;
end if;

By using the first version you explicitly explain to the reader that
there is something fishy going on when evaluating Operator_Is_Alerted,
since it may only be evaluated if Alarm_Is_On evaluates to true. Is
there something fishy going on, or are you just giving the reader
superfluous information, that may confuse him when he has to maintain
the code in 10 years time?

- Mark Lorenzen

Re: Short circuit boolean evaluation

[Simon Wright]

Mark Lorenzen <mark.lorenzen@ofir.dk> writes:

> if (Alarm_Is_On and then Operator_Is_Alerted) then
>   Wait_For_Operator;
> else
>   Call_Fire_Brigade;
> end if;

> By using the first version you explicitly explain to the reader that
> there is something fishy going on when evaluating Operator_Is_Alerted,
> since it may only be evaluated if Alarm_Is_On evaluates to true.

And I notice those superfluous parens!

-- 
Simon Wright                               100% Ada, no bugs.

Re: Short circuit boolean evaluation

[Mark Lorenzen]

Simon Wright <simon@pushface.org> writes:

> Mark Lorenzen <mark.lorenzen@ofir.dk> writes:
>
>> if (Alarm_Is_On and then Operator_Is_Alerted) then
>>   Wait_For_Operator;
>> else
>>   Call_Fire_Brigade;
>> end if;
>
>> By using the first version you explicitly explain to the reader that
>> there is something fishy going on when evaluating Operator_Is_Alerted,
>> since it may only be evaluated if Alarm_Is_On evaluates to true.
>
> And I notice those superfluous parens!
>
> -- 
> Simon Wright                               100% Ada, no bugs.

You got me! After 2.5 years of C/C++ programming I have already
started to loose the "touch". How shall this end?

- Mark Lorenzen

Re: Short circuit boolean evaluation

[Wes Groleau]

svaa wrote:
> I wouldn't call it a few  keystrokes, I use it in every condition. 

I'm sorry to hear that.  The short circuit form
sends a message to the compiler AND the reader
that in order to avoid an exception, the evaluation
must be short-circuited.

Using it where it isn't needed is misleading maintenance
programmers.  If your timing is so tight that you MUST
save one or two clock cycles that way, then you are still
in trouble after doing so.  At least, if you are doing it
for efficiency, say so in a comment.

Does the REQUIREMENTS spec have such low-level
implementation details as "test this one first
and then that one only if ..." ?  If no, then
why insist it be in the code?

-- 
Wes Groleau
-----------
Curmudgeon's Complaints on Courtesy:
http://www.onlinenetiquette.com/courtesy1.html
(Not necessarily my opinion, but worth reading)

Re: Short circuit boolean evaluation

[Steve]

"svaa" <svaa@ciberpiula.net> wrote in message
news:87f5a614.0311061144.360b3325@posting.google.com...
> "Steve" <nospam_steved94@comcast.net> wrote in message
news:<Vwjqb.115053$HS4.999172@attbi_s01>...
> > I consider it unimaginable to make such a fundamental change to a
language
> > in order to save a few keystrokes when more than a few billion lines of
> > source code might be effected.
>
> I wouldn't call it a few  keystrokes, I use it in every condition.
>
> Anyhow, that's not the problem, the problem is that short-circuit has
> clearly proved to be better...

That is a very strong statement.  Especially when you consider cases
where you are forcing in-order execution, essentially restricting the
compiler from generating code that might otherwise execute in parallel.

Of course in either case the compiler may determine that the result is the
same regardless of the order of execution and do the most efficient thing.

> clearly proved to be better, I supose that the idea of Ada0x is to add
> new features and remove flaws. Backward compatibility is a problem,
> but it could be resolved with pragmas etc. Most sofware have eventualy
> made changes that had backward compatibility problems. Probably a big
> problem with backward compatibility means a big improvent for future
> developments.

You appear to be stating that having control whether expressions use
short circuit evaluation or not is a flaw.   I disagree.  In fact I think
the
ability to express how you want things evaluated is a strong point of
the language.  It leads to fewer suprises.

> Sure we can live with full evaluation, but we can live better with
> short circuit. If we accept that short circuit is better than full
> evaluation...

Which I do not.

> the change must be done, sooner or later. This time is as
> good or bad as any another.

> Perhaps Ada0x could let the full evaluation as default, but add a
> pragma that allows short circuit, and in ada1x make it as default. (it
> doesn't means make illegal "and then" operator). Ada has fame of
> bloated and burden syntax, things like this doesn't help. I think it
> is time and make good changes, even if they are deep. It's not time to
> be conservative, but brave.

I would rather keep the so called "bloated syntax".

Incidently.  When moving a bunch of Pascal code to Ada, I was somewhat
suprised at how many bugs came up due to the weaker typing in Pascal.  Not
only bugs, but in some cases serious performance issues.

Coming from Pascal, you probably find it a drag that you have to explicitly
do time conversions in expressions.  I found one routine in the middle of a
fitting
procedure that was converted from Pascal to Ada using an automated tool.
When
I saw the amount of conversions happening between types to perform
operations
I was amazed.  I re-coded the procedure to turn things into a common type up
front
before doing the bulk of the work.  The routine was more than 2X faster.  I
went
back with my new found wisdom and changed the types used in the Pascal code
(just
out of curiousity).  I saw the same speed up there as well.

There is a lot to be said for being able to see exactly what is going on.
As well
as having the control to specify exactly what you want to happen.

Steve
(The Duck)

> Will we carry "and then" in ada5x? Will we accept that flaw (a minor
> flaw, but a flaw) in the first version must remain for ever?.

Re: Short circuit boolean evaluation

[Georg Bauhaus]

svaa <svaa@ciberpiula.net> wrote:
: "Steve" <nospam_steved94@comcast.net> wrote in message news:<Vwjqb.115053$HS4.999172@attbi_s01>...
:> I consider it unimaginable to make such a fundamental change to a language
:> in order to save a few keystrokes when more than a few billion lines of
:> source code might be effected.
: 
: I wouldn't call it a few  keystrokes, I use it in every condition. 

Hm. That indicates that you are writing tons of complicated
conditionals? Without having seen the particular programming
problem, might it not be worth considering a different
aproach to soving the programming problem?

Even if programmer productivity could be increased by a fraction
of n.m more lines of code, say, by making short circuit evaluation
implicit, what syntax do you propose for full evaluation?

(I guess n is 0 and m is close to 0, but not that
n is 0 and then m is close to 0 ;-)

Georg

Re: Short circuit boolean evaluation

[Gautier Write-only]

svaa:

> I'm a newbie in Ada, I've worked in several languages, last three
> years I've worked in Delphi (Pascal).

Welcome to professional programming...

Well. The efficiency of the "short circuit" is to be relativized,
especially with the processors of the last 10 years where each
condition (that automatically come with the short-circuit) means
a serious slowdown. This "short circuit is faster"-mania is completely
outdated. You find it in Delphi simply because it was already brought
into Turbo Pascal 20 years ago as a marketing argument. It worked
well on the PCs of these days and with a non-optimizing compiler
like Borland's. You'll find rapidly that
most of the time "and" and "or" as complete evaluation is better
and some cases like "a_boolean_variable and a_long_function"
naturally deserve the "and then", and of course "and then" means
clearly a short circuit. No problem there. Think also that a compiler
can also optimize much better "and" than "and then". It's also
good to see the assembler output and of course perform some comparative
timings. You'll be surprised...
Generally, what makes more sense "at reading" is also the most efficient.
If you want to save microseconds, tune the code...

[...]
> Standard pascal has full evaluation, but most compilers have an option
> for short circuit evaluation, and it's the default one, that should
> give a clue.

If you think to Delphi, it's wrong: the behaviour is set by an option
that you can default to what you want. In fact your program may have
a completely different behaviour if the compiler with which you compile
it has the checkbox "Complete Boolean Evaluation" set or not (see your
own words about side effects...). The {$B+} or {$B-} you can put
in the source is not a lot better (especially in include file).
This point is surely one of the worse mistakes (out of many) Borland
did in its language design. What was a nice gadget at its time has
become a burden because you have to put everywhere {$B+}'s or {$B-}'s
if you want to obtain a real efficiency. Frankly, "and then" and "or else"
are a bit more convenient, aren't they ?...
Not that standard Pascal has "and_then" and "or_else" for short circuits.

> Programs will have the same result if you change the behavior to short
> circuit, but you will save a lot of "then" and "else".
> 
> Well, I'm missing the case of expresions that call functions. If that
> function have side efects, you have to evaluate it. I think this is a
> bad coding style, but perhaps it's because I usually work with
> short-circuit. In this cases you would lose backward compatibility.
> Although it could be solved with a pragma.

You have little chance to bring Borland's blunders into Ada.
The best solution is to wait a bit of time. Borland makes you very
nostalgic (I know this feeling), but you will see, it will fade...
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Short circuit boolean evaluation

[Alexandre E. Kopilovitch]

Gautier Write-only wrote:

> > I'm a newbie in Ada, I've worked in several languages, last three
> > years I've worked in Delphi (Pascal).
>
> Welcome to professional programming...

I guess you confused Delphi with Visual Basic -:) . Actually there is enough
professional programming in Delphi (and *for* Delphi - I mean components here);
I'm not sure that number of professional Ada programmers exceeds that of Delphi
(percentage of professional programmers is certainly wildly higher for Ada,
but I think that overall number of Delphi programmers may be similarly higher
than the overall number of Ada programmers... including software engineers -:) .

As for original subject... I wish original poster go to some C/C++ newsgroup
with the similar proposition: let's change "||" and "&&" to "|" and "&" respectively,
and vice versa - for the same reasons -;) .




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Short circuit boolean evaluation

[Warren W. Gay VE3WWG]

Gautier Write-only wrote:
> svaa:
>>I'm a newbie in Ada, I've worked in several languages, last three
>>years I've worked in Delphi (Pascal).
> 
> Welcome to professional programming...
> 
> Well. The efficiency of the "short circuit" is to be relativized,
> especially with the processors of the last 10 years where each
> condition (that automatically come with the short-circuit) means
> a serious slowdown. This "short circuit is faster"-mania is completely
> outdated. 

This is neither universally true, nor false. I know that the
discussion is centered around boolean tests here, but a
boolean test often includes a function call that returns
a boolean value. You cannot unversally state that by always
calling the boolean function, that it is going to be just
as fast, or faster. You don't know how long that function
is going to run (obviously).

On the other side of the argument, the embedded folks have
pointed out that you _want_ to always invoke those functions
(ie. avoid short circuiting) so that you can reliably
predict and measure your CPU overhead. This is particularly
important when you have a low margin of excess CPU
capability. This also improves code path coverage, for
testing purposes. Both of these reasons are important for
life critical pieces of software.

But for any _other_ situation (in the general purpose
programming arena), I see following reasons to
support short circuit expressions:

   1. When the extra clauses are invalid (ie. don't evaluate
      beyond a short-circuit when a pointer is known to be
      null, for example)

   2. For efficiency (avoid computing unnecessary results,
      particularly in function calls, where the overhead is
      known to be large enough to care about).

The fact that it exists in the language suggests to me that
some folks have valid uses for the construct. When someone
starts saying that you must always use, always not use
something, then I would have to question the reasoning
behind that.

Finally, it may also depend upon the portability of the
code. Programming to Pentium IV whims may really hurt
you on another quite different platform, depending upon
the application and the choices made.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg