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-06 08:44:33 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!fu-berlin.de!uni-berlin.de!ppp-2-177.cvx5.telinco.NET!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Lazy Evaluation [Side-Effects in Functions] Date: Tue, 6 Nov 2001 16:18:12 -0000 Message-ID: <9s941c$11mrei$2@ID-25716.news.dfncis.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> NNTP-Posting-Host: ppp-2-177.cvx5.telinco.net (212.1.153.177) X-Trace: fu-berlin.de 1005065069 35352018 212.1.153.177 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: archiver1.google.com comp.lang.ada:15923 Date: 2001-11-06T16:18:12+00:00 List-Id: "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. 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. 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. -- Nick Roberts