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,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-02-26 01:45:04 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!adsl-213-200-246-247.cybernet.CH!not-for-mail From: Vinzent 'Gadget' Hoefler Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions Date: Thu, 26 Feb 2004 10:44:22 +0100 Organization: JeLlyFish software Message-ID: References: <4020C947.81A6D703@0.0> <1075907239.138068@master.nyc.kbcfp.com> <402232E9.3EE15B4B@0.0> <1075987360.225622@master.nyc.kbcfp.com> <40236C0B.E988E003@0.0> <1077634311.254581@master.nyc.kbcfp.com> <82347202.0402251405.2db2f3c5@posting.google.com> <1077747598.55635@master.nyc.kbcfp.com> NNTP-Posting-Host: adsl-213-200-246-247.cybernet.ch (213.200.246.247) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: news.uni-berlin.de 1077788702 53213494 I 213.200.246.247 ([175126]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:5834 Date: 2004-02-26T10:44:22+01:00 List-Id: Hyman Rosen wrote: >Jim Rogers wrote: >> But how does his order of evaluation work with named notation? > >I would go with the order of the actual parameters, >not the order of the formal parameters. One goal of >specifying evaluation order is to have unsurprising >behavior, so saying > Battery(Catcher =3D> GetName, Pitcher =3D> GetName); >should assign the first name read to Catcher and the >second to Pitcher, regardless of the order of the formal >parameters of Battery. Yes, and that is a very good example on how to write bad code. First: GetName is obviously a function with side-effect, second it relies on a specific calling order. If you want a specific order, do it explicitely: |Tmp_Name_1 :=3D GetName; |Tmp_Name_2 :=3D GetName; | |Battery(Catcher =3D> Tmp_Name_1, Pitcher =3D> Tmp_Name_2); >I can't at the moment think of a good reason for doing it >the other way from the programmer's point of view, Well, my point of view to the original code would be that it doesn't matter which name gets assigned to which parameter. >rather than for the convenience of the compiler. Yes, true. But Ada is - like a lot of others - a programming language that is supposed to get compiled some day. And sometimes language designers should keep an eye on this if they want a language to be used outside of purely theoretical and/or educational areas. So it might be possible that in the parsing/compiling process the order specified in the named notation simply gets reordered to the order of how the parameters are declared. Well, even this still doesn't mean, that this would be the order in which the functions are called in the end. I think, all this discussion about execution order is a little bit senseless when today we have processors that do explicit instruction reordering and even have parallel execution support. Even if the compiler issues code where the execution order is fixed that doesn't mean that the processor will execute it this way. And you don't want the compiler to emit one serializing instruction after another just to make sure that the execution order does not change, do you? IMO, it is easier to just not rely on side-effects. No side-effects, no problems. Vinzent.