Re: and then... (a curiosity)

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

stefan-lucks@see-the.signature schrieb:

> True. But the case that you want both expressions to be evaluated is a 
> rare exception. On a *logic* level, "A and B" implies "if A is false, the 
> result is false, regardless of B". So short-circuit evaluation is a 
> natural and good thing for a programming language, and it is regrettable 
> that Ada needs a more complex syntax for this.

That's not what I learned in my boolean arithmetic classes.

> (Well, "A and B" also 
> implies "if B is false, don't care about A", but in a programming language 
> you can't have it both ways.)

That is what I learned in my boolean arithmetic classes. It's either
way. There is no preference that the left parameter if more important
then the right. A Human seeing "A∧0" won't evaluate A. And if you see
"f(x)∧g" you would probably evaluate g first as a variable is usually
easier to evaluate then a function.

And it is what you have in Ada - with plain old "and" and "or" the
optimizer is free to do out of order evaluation and dead code
elimination which could well lead to B being evaluated first and A being
optimized away if B already determines the final result.

This - of course - only if the compiler can also determine that A and B
have no side effect. Side effect are that little difference between
arithmetic and programming. The CONSTRAINT_ERROR in:

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

or the global variable which f(x) might change:

function f(x:Integer) is
begin
   if x > 10 then
     g = false;
   end if;
   return x > 5;
end f;

It's all about those side effect which make order of evaluation so
important. Otherwise it should not matter.

Note that once you add:

pragma Inline (f);

to the example above things become very interesting for the optimizer
;-) (do remember that the optimizer will use goto without shame).

> But, as others pointed it: IF the default "and" supported 
> short-circuit-evaluation, THEN this "and" could not be an ordinary Ada 
> operator. At the language semantic level, it is much more reasonable to 
> treat "and" like any other operator or function, such as "+" and "-".

Well again, in my arithmetic classes I learned that a+b is the same and
b+a - which includes that the order of evaluation is of no importance.
If you want that ∧ operates the same way as + then "a∧b" must be the
same as "b∧a".

Martin

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