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-28 19:51:59 PST
Path: 
 archiver1.google.com!news2.google.com!news.maxwell.syr.edu!news-out1.nntp.be!propagator2-sterling!news-in.nuthinbutnews.com!cyclone1.gnilink.net!spamkiller2.gnilink.net!nwrdny03.gnilink.net.POSTED!0e8a908a!not-for-mail
From: Hyman Rosen <hyrosen@mail.com>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: In-Out Parameters for functions
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> <xay_b.429$ax2.177@nwrdny03.gnilink.net>
 <pan.2004.02.24.01.44.30.311621@email.ro>
 <1077634311.254581@master.nyc.kbcfp.com>
 <pan.2004.02.24.23.23.33.578111@email.ro>
 <mailman.20.1077669870.327.comp.lang.ada@ada-france.org>
 <pan.2004.02.25.09.01.17.858502@email.ro>
 <1077718871.47635@master.nyc.kbcfp.com>
 <54cp3095jmv8s17h63d4bjdus0tec7l7pt@jellix.jlfencey.com>
 <1077721343.481619@master.nyc.kbcfp.com> <LIidnT3Ca4JDVaHdRVn-jw@comcast.com>
 <1077727853.904323@master.nyc.kbcfp.com> <B8WdnRy5IL0WaqDdRVn-jA@comcast.com>
 <1077810250.28474@master.nyc.kbcfp.com> <YLSdnQ0lYfaSTN3dRVn-iQ@comcast.com>
In-Reply-To: <YLSdnQ0lYfaSTN3dRVn-iQ@comcast.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <zld0c.8152$qX5.3749@nwrdny03.gnilink.net>
Date: Sun, 29 Feb 2004 03:51:59 GMT
NNTP-Posting-Host: 162.84.141.199
X-Complaints-To: abuse@verizon.net
X-Trace: nwrdny03.gnilink.net 1078026719 162.84.141.199 (Sat,
 28 Feb 2004 22:51:59 EST)
NNTP-Posting-Date: Sat, 28 Feb 2004 22:51:59 EST
Xref: archiver1.google.com comp.lang.ada:5940
Date: 2004-02-29T03:51:59+00:00
List-Id: <comp.lang.ada>

Robert I. Eachus wrote:
>  It is that you will find lots of places in the standard where
> order independent SEMANTICS occurs, for example in 13.7.1(7).  In those 
> cases the usual implementation (in this case of package 
> System.Storage_Elements) will simplify things by using parameter 
> flipping and pragma Inline.  If we were to change the semantics of Ada 
> to require left-to-right evaluation, what should be done with these 
> functions, especially when they are in-lined?  A workable rule probably 
> could be written, but it is the sort of thing you have to look at with a 
> proposal like yours.

The section to which you refer defines a pair of "+" operations.
I don't see how they cause any issues for l-to-r. And pragma Inline
does not affect the semantics of a program, so again I don't see what
the relevance is. I do agree that there seem to be unholy complexities
lurking in the trade-offs between checking requirements and allowing
optimization which could be exacerbated by requiring l-to-r.