From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,f0ba82308a594485
X-Google-Attributes: gid103376,public
From: Laurent Guerby <guerby@acm.org>
Subject: Re: Right of Optimize Eager Evaluation Away
Date: 1999/11/29
Message-ID: <86iu2lvyed.fsf@ppp-105-76.villette.club-internet.fr>#1/1
X-Deja-AN: 554550824
References: <863dtqfo26.fsf@ppp-173-146.villette.club-internet.fr>
 	<wccr9haibu3.fsf@world.std.com>
 	<861z9afhgd.fsf@ppp-173-146.villette.club-internet.fr>
 	<38420578.D6692D2E@callnetuk.com> <wccemd9z2k5.fsf@world.std.com>
X-Trace: front6.grolier.fr 943906842 21800 194.158.105.76 (29 Nov 1999
 20:20:42 GMT)
Organization: Club-Internet (France)
NNTP-Posting-Date: 29 Nov 1999 20:20:42 GMT
Newsgroups: comp.lang.ada
Date: 1999-11-29T20:20:42+00:00
List-Id: <comp.lang.ada>

Robert A Duff <bobduff@world.std.com> writes:
> > Laurent Guerby wrote:
> 
> > > Is the potential raising of an exception the only language barrier
> > > here (since as you mention the compiler is free to swap calls
> > > defeating a class of side effects)? This seams easy to fix (via a
> > > pragma), if one is interested in keeping the functional aspect of the
> > > code instead of resorting to statements of course.
> 
> I don't understand Laurent's question.

I should rephrase then ;-):

Is the potential raising of an exception the only language barrier
to allow lazy evaluation for an optimizing compiler?

It looks like to me that the Ada language more or less intend that
functions shouldn't have side effects, since by example it allows the
compiler to evaluate arguments and thus potentially calling functions
in any order, or allows only "in" parameters for the programmer.

The question is then, why stop at allowing any evaluation order and
not just allow lazy evaluation as well?

It allows some "nice" optimizations, like the one I mentionned, or
things like:

-- In some Debug package body:

   Enable_Trace : constant Boolean := True; 
   -- or set to False when compiled in "release" mode
   
   procedure Trace (M : in String) is
   begin
      if Enable_Trace then
          IO.Put (M);
      end if;
   end Trace;

-- Now you have your code full of Trace calls like:

   Trace ("index = " & Image (Index) & " value = " & Image (Value));

With the current RM, even if the compilers know that the Trace call
doesn't do anything (inlining is on, and proper unreached code
elimination has been done), it cannot suppress the calls to Image or
to "&" since they might potentially raise an exception. The only way
to do a "release"/"debug" switch that does not cause a performance
penalty for the "release" version is then to use vendor specific
pragmas like GNAT Assert or Debug, and thus is outside of the
language.

The "pragma" I was mentionning could look like:

pragma You_Can_Omit_Calls_To_This_If_The_Value_Is_Not_Needed (F);

(obviously a better name is needed ;-). If an expression involves only
calls to pragma'ed functions (the Standard and String stuff could be
in this category for example), then if the compiler finds out the
result isn't needed in some run-time paths, it can omit the evaluation
of the expression in those paths.

I don't know if I'm clearer here ;-).

> - Bob

--LG