Re: left-to-right (was In-Out Parameters for functions)

From: Stephen Leake (Stephe.Leake_at_nasa.gov)
Date: 02/27/04 

Date: 26 Feb 2004 23:58:22 -0500
To: comp.lang.ada@ada-france.org

Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:

> On 24 Feb 2004 19:44:12 -0500, Stephen Leake <stephen_leake@acm.org>
> wrote:
>
> >I think Hyman has two valid points:
> >
> >1) if the language specified left-to-right order, there would never be
> > a need to "kill the original smart-ass programmer"
>
> But also, if the language disallowed side-effects when there could be
> more than one order. I prefer the second, provided that the term
> "side-effect" should be formally defined by the language and visible
> from the specifications.

That's never going to happen!

> >2) Does anyone have a real example of a compiler taking advantage
> >of the evaluation order freedom to speed up a program?
>
> The question is what gets lost if an evaluation order is fixed. I gave
> an example earlier:
>
> for I in A'Range loop
> Sum := Sum + A (I) + B (B'First + I - A'First);
> ...
>
> Here with left-to-right order the compiler cannot optimize neither the
> array index of B,

What do you mean by "optimize" in this sentence? the array index of B
is B'First + I - A'First. It must be computed before B(). In what way
would this be done differently by a "real Ada" compiler vs a
"left-to-right" Ada compiler?

> nor can it increment Sum by adding A()+B().

True; it must compute temp := Sum + A(), then Sum := temp + B(). What
difference does that make, in actual practice? How many compilers do
anything else?

Hmm. For scalars, if A and B happen to be in registers, and Sum in
ram, I can see compilers messing with the order. Can anyone confirm
that actually happens in real compilers? It's been a while since I
messed with gcc code generation.

> Well, these optimizations could be made possible if the compiler
> might prove that the result does not depend on the order. That could
> be quite difficult to formally define, especially regarding numeric
> exceptions and floating-point accuracy stuff. Even more difficult it
> would be check.

That is _precisely_ the point. Since it is difficult to formally
define and check the meaning of "does not depend on order", why do we
expect people to be able to do it?

On the other hand, that's also why it's not likely such restrictions
will be added to the definition of "pure" functions in Ada.

> But finally, if all that could be achived, then the compiler will be
> capable to simply detect that different orders give different
> results, and threat it as an error. Much better than fixing an
> arbitrary order!

Why is that better? The goal is to have code that works (meaning
produces correct results :), on all compilers/platforms. If I only
have to prove that one evaluation order is correct, that is easier
than if I have to think about many evaluation orders.

> So the bottom line, IMO, 1 makes no sense.

But you haven't answered my question. Is there, in actual fact, any
compiler that actually does these optimizations?

> >Ada is supposed to be about clear, unsurprising code. Subtle order
> >issues are just that - "subtle". If the language _could_ make them a
> >non-issue, at very little cost, I think it _should_.
>
> Right, the present situation is not good. But IMO the solution lies in
> introducing formally pure functions and imposing limitations on use of
> impure functions (and procedures with results) in expressions.

That's way more work than simply requiring left-to-right, and
therefore far less likely to happen. 

-- 
-- Stephe

Relevant Pages

  • Re: In-Out Parameters for functions
    ... > evaluation order then the compiler can evaluate it in any order it wants, ... > that have more than one possible value based on evaluation order. ... As has already been pointed out in this thread, an Ada ... Stuart Palin ...
    (comp.lang.ada)
  • Re: Benefit of not defining the order of execution
    ... What about all that code out there that depends on a compiler's current evaluation order which is different from your proposed standard? ... Sure, it'd break if the compiler folks decided to do something different, but the compiler folks are aware of that and the order of evaluation they use is generally tied to system-specific details inherent to the platform. ...
    (comp.lang.c)
  • Re: c = foo(--a) + a; ?
    ... evaluation order remains unspecified: It's to give the ... compiler leeway to apply useful optimizations that produce ... the same effect as the original code without the expense ... Ignoring optimizations completely, what about a very simple compiler which evaluates all operands in left-to-right order, and creates a simple postfix version of the expression? ...
    (comp.lang.c)
  • Re: I/O in PURE and ELEMENTAL procedures in Fortran 2008
    ... If it seemed so to you it was an accident of code generation ... DIDN'T short-circuit as evidence that this was not deliberate nor ... I remember looking at the code generated by the compiler, and noticing that it had re-arranged the evaluation order and suppressed evaluating the second argument of the AND when the first already fixed the result. ...
    (comp.lang.fortran)
  • Re: Current status of Ada?
    ... learning and using this great language. ... The reason why compilers maker can't make their compiler totally free ... I agree with you that most of the links you can find on Ada websites ... AdaCore has contributed a free gnat compiler to ...
    (comp.lang.ada)