Re: and then... (a curiosity)

["Santiago Urueña" <suruena@gmail.com>]

> I don't buy that argument, because the semantics of "A and B and C"
> are identical to the semantics of "A and then B and then C" (when A, B,
> and C are Boolean variables), so the compiler is free to generate
> identical code for both.  If efficiency is important in this case,
> the compiler should be trained to make it efficient, and the programmer
> shouldn't have to worry about it.
>
Yes, I suppose that's why at AdaCore the convention is to use always
short-circuit boolean operators, because gnat can generate the
optimized code anyway for just boolean flags.

> Your point for (non-inlined) function calls is valid, though -- the
> compiler can't be expected to know what's in the function in general.
>
It is interesting that in Spark the compiler can always optimize these
two cases completely, because the functions are always pure. Idea:
pragma Profile (Spark)

Having said that, even if the performance can be improved, I don't
like that rule neither because then when the maintainer sees an "and
then" operator she cannot know whether it is just for performance
reasons or you really want to avoid some side effects (unless some
comments are added).

I agree that those micro-optimizations should be done by the compiler,
so even if the programmer doesn't write the short-circuit operators
when function calls are involved, the compiler should be smart enough
to generate lazy evaluation (if the functions are pure).

Cheers,