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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-02-04 11:58:48 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!wn14feed!worldnet.att.net!bgtnsc04-news.ops.worldnet.att.net.POSTED!not-for-mail From: David Starner Subject: Re: In-Out Parameters for functions User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity. (Debian GNU/Linux)) Message-Id: Newsgroups: comp.lang.ada References: <1075732402.294581@master.nyc.kbcfp.com> <1075741279.952497@master.nyc.kbcfp.com> <16nu1099ekujjbpe9dqvs3noi9sdcfja6e@4ax.com> <1075817212.745748@master.nyc.kbcfp.com> <1075824683.769215@master.nyc.kbcfp.com> <1075851506.238480@master.nyc.kbcfp.com> <906120pv9cnj95mgmq3lt07nvtcidv32uc@jellix.jlfencey.com> <1075906659.895321@master.nyc.kbcfp.com> <3o2220pqojg2g36aim7dijnb5470612md9@jellix.jlfencey.com> <1075909934.743015@master.nyc.kbcfp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Wed, 04 Feb 2004 19:58:47 GMT NNTP-Posting-Host: 12.72.183.196 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 1075924727 12.72.183.196 (Wed, 04 Feb 2004 19:58:47 GMT) NNTP-Posting-Date: Wed, 04 Feb 2004 19:58:47 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:5243 Date: 2004-02-04T19:58:47+00:00 List-Id: On Wed, 04 Feb 2004 10:52:14 -0500, Hyman Rosen wrote: > What is it about definite order of evaluation that you and so > many others find intrinsically evil? Have you ever studied functional programming? I think part of the objection is the concept that pure functional programming is the ideal and that we differ from that for efficiency and a closer mapping to the hardware. Also, half the examples have been horrible code that should never be written. So much of the code enabled by this feature can't be fixed to use it without a program-wide analysis of the problems, wherein it would be just as easy to fix the code not to depend on evaluation order. > OK, I accept that there are more ambiguity issues than I have > been cnsidering. I suppose you object to getting rid of those too? That would require major surgery to the language that would leave it backwardly-incompatible or require the compiler to do stupid slow things. If you want Java, you know where to find it. In any case, you have a huge group of ambiguity issues around threads. It's inherent in the system. If you're worried about your compiler changing evaluation order at compile time, wait until your program starts behaving erratically at run time because you made the same mistakes. > But using functions that read input is not hard to reason about. > BunchOfReadings : array(1..100) of Integer := (others => ReadSensor); Which it is easy to warn about and simple to fix. > But it's not, except for programs which are now exhibiting unspecified > behavior. If an expression has only one value regardless of execution > order, then the compiler will be free to evaluate it in any order. If the compiler can prove that, which is easier said then done. At best, it will slow down compilers at compile-time, proving what they could assume before, and slow down programs at run-time when they couldn't prove it.