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: Niklas Holsti Subject: Re: Right of Optimize Eager Evaluation Away Date: 1999/11/29 Message-ID: <3842F57A.C3AE4872@icon.fi>#1/1 X-Deja-AN: 554572522 Content-Transfer-Encoding: 7bit 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> Content-Type: text/plain; charset=us-ascii X-Trace: read2.inet.fi 943910677 194.252.1.67 (Mon, 29 Nov 1999 23:24:37 EET) Organization: Space Systems Finland Ltd MIME-Version: 1.0 NNTP-Posting-Date: Mon, 29 Nov 1999 23:24:37 EET Newsgroups: comp.lang.ada Date: 1999-11-29T00:00:00+00:00 List-Id: Laurent Guerby wrote: [ snip ] > > 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? I think you could define a language like that. The question is how it would be related to the (current) Ada language. It seems sure to be incompatible with side-effecting functions, even if differences in exception-raising are allowed. RM 1.1.3(8) lists the external effects that should be preserved by optimisation. There seem to be some that can be sensibly used by programmers without knowing the evaluation order, but yet cannot be omitted totally without harming the program's result: - setting the value of imported or exported objects (independent of order if the functions used in the parameter expressions set different objects) - reading or updating atomic or volatile objects (may be independent of order if the functions read/update different objects). In other words, some programs could use side-effects of this type, and still work whatever evaluation order is chosen. So to apply lazy evaluation, the compiler should ensure that no such effects can occur as side-effects of the lazily evaluated functions. In practice, I would add any task interactions to this list. Given a function that interacts with tasks, it seems quite unlikely that the compiler could prove that omitting the task interactions would not make any significant difference to the external effects, yet there must be many cases in which the evaluation order of such functions is not in fact significant for the correctness of the program. > 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. Isn't pragma Pure (10.2.1(18)) something like this? Is it too restrictive for you? Regards, Niklas Working at but not speaking for Space Systems Finland Ltd.