Re: Right of Optimize Eager Evaluation Away

[Laurent Guerby <guerby@acm.org>]

Robert A Duff <bobduff@world.std.com> writes:
> If you have two sub-expressions with side effects, they can happen in
> either order.  That does make side effects less useful, but it is still
> possible to write code so that the side effects are independent of each
> other, so order doesn't matter.
> 
> In other words, the Ada rules encourage bugs in programs with side
> effects, but they don't outlaw side effects.  Nor do they give the
> optimizer permission to ignore side effects.

Well, that was my point, Ada makes the life of side-effect function
writers difficult in its current incarnation, in the sake of potential
optimization. Why not make another step, and allow lazy-style
optimization for Ada, at least under the control of a pragma?

> It seems to me that if you're going to do lazy evaluation for all
> function calls, then you really ought to be using a pure functional
> language.

I never said "all", that's the point of Ada, you can use the paradigm
you find adapted to your specific problem (simple private record, full
OO, functional with Pure, ...).

The state oriented part of the so-called pure functional languages I
know is just awful.  And I think most software will do state _and_
function, so I want to have a state oriented paradigm at hand when I'm
handling state so I can write code in a "natural" way, a functional
paradigm when I'm writing pure functions, and an high-level concurrent
paradigm when I'm writing the concurrent part, etc...

> > -- Now you have your code full of Trace calls like:
> >    Trace ("index = " & Image (Index) & " value = " & Image (Value));
> If you make put pragma Pure on Image, it can be optimized.

No, see below.

> > pragma You_Can_Omit_Calls_To_This_If_The_Value_Is_Not_Needed (F);
> > (obviously a better name is needed ;-).
> How about calling it Pure?  ;-)

Because, as I said, Pure doesn't allow the compiler to omit the call
(it can call the thing only once if the parameters don't change, or be
more aggressive and generate memo-izing code), just in case an
exception might happen. That's the point I made about the potential
exception raising being the only language barrier to the lazy
evaluation feature. You added independant side effects to the list,
but I would gladly drop or restrict this dubious feature in favour of
better potential optimization.

Or having the well-named pragma I proposed, since Pure doesn't do
the job I want to here ;-).

Also, Trace package and the like are unlikely to be Pure (but you can
use the Import trick to make them Pure as I mentioned it a few years
ago on this newsgroup ;-).

--LG