Re: and then... (a curiosity)

[Martin Krischik <krischik@users.sourceforge.net>]

Ray Blaak schrieb:
> Martin Krischik <krischik@users.sourceforge.net> writes:
>> 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.
> 
> 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.

> This instinct is
> reenforced both from the current popular languages as well as from formal
> proof styles in programming methodology.

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.

> So, I don't like relying the execution of both disjuncts. Sure, I could use
> "or else" consistently, but I like thinking of boolean or as good old regular
> boolean or.

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.

If the optimizer determines that the 2nd expression has no side effects
it might optimize it away. But note that raising CONSTRAINT_ERROR is a
side effect. So:

if X /= null and x.all = 5 then
  Do_Something;
end if;

will most likely become:

if x = null then
  raise CONSTRAINT_ERROR;
elif x.all = 5 then
  Do_Something;
end if;

Or - for a CPU with hardware null pointer detection - it might become:

if x.all = 5 then
  Do_Something;
end if;

Ada is a language which highly rely on the existence of an optimizer.
Unlike the C style languages - the very first C did not have an
optimizer and it still show in the syntax and semantic.- One should
always remember C's main design goal: compiler must fit's into 8 kb of
memory. It explains a lot.

Anyway by default Ada leaves all option options open to the optimizer.
For example:

type Byte is range -128 .. 127;

might not actually be a byte - especially when optimized for
performance. By default all options are open to the optimizer to make
the best of you wish. Only when you start restricting the optimizer with

for Byte'Size use 8;

you are guaranteed an 8 bit type.

You consider this when thinking of "or else" and "and then" - both
restrict the optimizer in it's doing and the result might not be faster.

Regards

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