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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.52.246.236 with SMTP id xz12mr40620390vdc.10.1438156365484;
 Wed, 29 Jul 2015 00:52:45 -0700 (PDT)
X-Received: by 10.140.36.170 with SMTP id p39mr593041qgp.28.1438156365459;
 Wed, 29 Jul 2015 00:52:45 -0700 (PDT)
Path: 
 buffer1.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!69no2569872qgl.1!news-out.google.com!b31ni1088qge.0!nntp.google.com!69no2569870qgl.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Wed, 29 Jul 2015 00:52:45 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.20.1507290857520.3461@debian>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=81.203.145.32;
 posting-account=AFCLjAoAAABJAOf_HjgEEEi3ty-lG5m2
NNTP-Posting-Host: 81.203.145.32
References: <e610ca1e-4df6-4fbb-b3a1-ac35694d9072@googlegroups.com>
 <mp7pn9$mb3$1@dont-email.me> <1ckwx9hern944$.1w0k6fbvlqo62$.dlg@40tude.net>
 <fddb0ac0-6554-44d6-9c23-7c23883884d3@googlegroups.com>
 <1ipfeas9434z5.o8661mp0cpkh.dlg@40tude.net>
 <75a31df9-801e-4e7f-8e29-403c0650c891@googlegroups.com>
 <alpine.DEB.2.20.1507290857520.3461@debian>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <53238a9a-1b46-457a-98d7-29d8db4ce165@googlegroups.com>
Subject: Re: Running a preprocessor from GPS?
From: EGarrulo <egarrulo@gmail.com>
Injection-Date: Wed, 29 Jul 2015 07:52:45 +0000
Content-Type: text/plain; charset=ISO-8859-1
Xref: number.nntp.giganews.com comp.lang.ada:194423
Date: 2015-07-29T00:52:45-07:00
List-Id: <comp.lang.ada>

On Wednesday, July 29, 2015 at 9:24:20 AM UTC+2, Stefan...@uni-weimar.de wrote:
> On Tue, 28 Jul 2015, EGarrulo wrote:
> 
> > On Tuesday, July 28, 2015 at 2:54:50 PM UTC+2, Dmitry A. Kazakov wrote:
> >
> >> You can inline the suggested wrapper and hope that the compiler indeed does
> >> inlining than effectively will make it lazily evaluated.
> >
> > I can't understand what you mean here.  Would you please explain
> > further?  Thank you.
> 
> I am not Dmitry, but here is what I frequently do (I actually have a 
> package Debug for that). The declaration is as follows:
> 
> procedure Trace(Do_It: Boolean; Message: String) with Inline;
> 
> The implementation is
> 
> procedure Trace(Do_It: Boolean; Message: String) is
> begin
>    if Do_It then
>        Ada.Text_IO.Put_Line(Trace_File, Message);
>    end if;
> end Trace;
> 
> In your program, you just write
> 
> Me_Active: Constant Boolean := True;
>    -- change this to False if you don't want to trace Me.
> 
> Debug.Trace(Me_Active, "Performing Step " & Step(Me));
> 
> Now the compiler (well, gnat -- I have no clue what other compilers will 
> do) will first inline the code inside Debug.Trace and, if Active_Me is 
> False, and the function Step has no side effects, the compiler will 
> eliminate the dead code -- at least, if you switch on the optimization.
> 
> Actually, this is *not* lazy evaluation: If Step has side effects, Ada 
> requires to evaluate it, even if Me_Active is False. A lazy language would 
> not evaluate Step. But in the given case, who would want to call some 
> function Step with side effects?

Thanks.  However, my understanding is that the inlining is unpredictable.  According to the RM 6.3.2 (emphasis mine):

"**For each call**, an implementation is free to follow or to ignore the recommendation determined by the Inline aspect. "