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: Robert A Duff Subject: Re: Right of Optimize Eager Evaluation Away Date: 1999/11/29 Message-ID: #1/1 X-Deja-AN: 554565375 Sender: bobduff@world.std.com (Robert A Duff) References: <863dtqfo26.fsf@ppp-173-146.villette.club-internet.fr> <861z9afhgd.fsf@ppp-173-146.villette.club-internet.fr> <38420578.D6692D2E@callnetuk.com> <86iu2lvyed.fsf@ppp-105-76.villette.club-internet.fr> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1999-11-29T00:00:00+00:00 List-Id: Laurent Guerby writes: > Is the potential raising of an exception the only language barrier > to allow lazy evaluation for an optimizing compiler? No. > 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. Side effects are allowed in Ada. It's true that functions can't have 'in' parameters, but they can modify globals and heap objects. (As Robert Dewar likes to point out, functions can have side effects, so long as you don't document that fact in the parameter profile!) The rule is that the side effects must happen. 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. > The question is then, why stop at allowing any evaluation order and > not just allow lazy evaluation as well? Because Jean Ichbiah said so. ;-) 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. > 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)); If you make put pragma Pure on Image, it can be optimized. Unfortunately, you can't easily do that in all cases. > 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 ;-). How about calling it Pure? ;-) >... 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 ;-). Yes. > > - Bob > > --LG