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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ce0900b60ca3f616 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-07 01:28:59 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: dmitry@elros.cbb-automation.de (Dmitry A. Kazakov) Newsgroups: comp.lang.ada Subject: Re: Lazy Evaluation [Side-Effects in Functions] Date: Wed, 07 Nov 2001 09:28:56 GMT Message-ID: <3be8f660.2085921@News.CIS.DFN.DE> References: <9rti6v$hcu$1@news.huji.ac.il> <1EyE7.10050$xS6.13527@www.newsranger.com> <9rue9f$j4t$1@nh.pace.co.uk> <9ruiet$kqg$1@nh.pace.co.uk> <3BE3235D.E292B890@boeing.com> <3BE35498.9F6381A2@acm.org> <9s230d$107b5a$2@ID-25716.news.dfncis.de> <5ee5b646.0111040507.5ca7ea23@posting.google.com> <9s3tl3$111hco$1@ID-25716.news.dfncis.de> <5ee5b646.0111041846.93f3e07@posting.google.com> <9s5eub02j61@drn.newsguy.com> <3be666fe.6426140@News.CIS.DFN.DE> <9s7bfb$11boa1$1@ID-25716.news.dfncis.de> <3be7a31d.1736453@News.CIS.DFN.DE> <9s941c$11mrei$2@ID-25716.news.dfncis.de> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) X-Trace: fu-berlin.de 1005125337 36237769 212.79.194.111 (16 [77047]) X-Newsreader: Forte Free Agent 1.21/32.243 Xref: archiver1.google.com comp.lang.ada:15977 Date: 2001-11-07T09:28:56+00:00 List-Id: On Tue, 6 Nov 2001 16:18:12 -0000, "Nick Roberts" wrote: >"Dmitry A. Kazakov" wrote in message >news:3be7a31d.1736453@News.CIS.DFN.DE... >above? The answer is no. >> ... >> P.S. A comment about computation order. I am not sure, but maybe it >> would be worth to think about introducing lazy parameters (Algol's by >> name). Ada already has them hard-wired in "and then" and "or else". >> The order lazy parameters are evaluated is obviously defined by the >> implementation of the subroutine, thus the above problems will >> disappear, or better to say, become the responsibility of the >> implementation. In your example "&" should have the second parameter >> lazy, so >> >> Decode(Data(1..4)) & Decode(Data(5..8)); >> >> would mean: evaluate Decode(Data(1..4)); call "&", which internally >> calls Decode(Data(5..8)). > >Briefly, the combination of lazy evaluation and side-effects, as such, would >be rather like the combination of a keg of TNT and a blowtorch. > >The problem of side-effects in Ada would be largely solved by fixing the >order in which arguments are evaluated (e.g. strictly in the order they are >declared) for all functions. But this would be a pity in that it would >significantly hamper many compilers' efforts to optimise a lot of ordinary >code. Yes. Then fixing the order does not solve another problem of side-effects: when same objects are visible through different arguments. The problem is of course in-out parameters per se. To the list of their "crimes": LSP violation by generalization or specialization; interesting effects in by-value vs. by-reference parameter passing etc. >Lazy evaluation is an interesting idea. How about: > > function Sin (X: delay in Float) return Float; > >where the 'delay' means that what is passed into Sin is an access value to a >temporary routine (X'Computation) that computes the required value of X. In >the body of Sin, a flag X'Computed is set False, and any reference to X >either: if X'Computed is False, causes a call to the temporary routine, >places the result into a temporary store for X, and sets X'Computed to True; >if X'Computed is True, retrieves the value of X from its temporary store. >Hey presto! Lazy evaluation. "and then" and "or else" could become first >class citizens. Something like this. Maybe pragma Volatile (X) should ensure that X is computed each time it is accessed. Otherwise, X is computed only once. Then (a crazy idea), it would be nice to have an ability for a lazy parameter to evaluate discriminants (and type tags) separately from the value. I do not know whether it possible, but it could solve the "problem of measurement units". The type of dimensioned values will have a discriminant specifying the unit of measure. Being static (in most cases) it can be evaluated statically (for inlined subroutines), thus units checks can be efficiently removed by the compiler. >The access value X'Computation would be subject to the same accessibility >rules as any other access (-to-subprogram) value. This business is, I guess, >closely related to that of lambdas etc. > >I not actually saying that I like this idea, by the way, just that it's >intriguing. It would be a dangerous stuff in right hands (:-)). Then I think to get pragma Inlined working efficiently for subroutines with lazy parameters would be not very easy. Regards, Dmitry Kazakov