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 Subject: Re: Right of Optimize Eager Evaluation Away Date: 1999/11/30 Message-ID: <86zovv934u.fsf@ppp-240-236.villette.club-internet.fr>#1/1 X-Deja-AN: 554969220 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> X-Trace: front2m.grolier.fr 943990795 10063 195.36.240.236 (30 Nov 1999 19:39:55 GMT) Organization: Club-Internet (France) NNTP-Posting-Date: 30 Nov 1999 19:39:55 GMT Newsgroups: comp.lang.ada Date: 1999-11-30T19:39:55+00:00 List-Id: Robert A Duff 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