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-25 08:10:08 PST
Path: 
 archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!news.gtei.net!newsfeed1.easynews.com!newsfeed3.easynews.com!easynews.com!easynews!border1.nntp.sjc.giganews.com!nntp.giganews.com!local1.nntp.sjc.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 25 Feb 2004 10:10:06 -0600
Date: Wed, 25 Feb 2004 11:10:05 -0500
From: "Robert I. Eachus" <rieachus@comcast.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
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>
In-Reply-To: <1077721343.481619@master.nyc.kbcfp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <LIidnT3Ca4JDVaHdRVn-jw@comcast.com>
NNTP-Posting-Host: 24.147.77.160
X-Trace: 
 sv3-snGe+jImP0RYI+krSKQNIoEZNZxT8I501+f671v6KFbMFSs+OBuPGon2IIut+Q0/ksNzKkpOJxlLFZj!j/xvzneEhvwzYZ28QKGhg5hKYeyLXsnFikdHvxHf6JYZQ0X9lals024QkFjaIg==
X-Complaints-To: abuse@comcast.net
X-DMCA-Complaints-To: dmca@comcast.net
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint
 properly
X-Postfilter: 1.1
Xref: archiver1.google.com comp.lang.ada:5796
Date: 2004-02-25T11:10:05-05:00
List-Id: <comp.lang.ada>

Hyman Rosen wrote:

> But Ada does not have that philosophy, so that cannot be the reason
> to maintain the feature. When "+" is a user-defined subprogram, its
> operands are always passed in the order written; a + b is always
> invoked as "+"(a, b) and never as "+"(b, a).

Absolutely wrong.  If I or any other Ada programmer defines an abstract 
type Foo, and it makes sense to add Integers to Foo, and the semantics 
of addition are commutative, I will declare:

function "+"(L: Foo; R: Integer) return Foo is...

function "+"(L: Integer; R: Foo) return Foo
is begin return R+L; end "+";

This is standard programming practice because it reflects the underlying 
semantics.  In fact I will probably provide "-" operations as well, 
defined as return L+(-R) and R+(-L) respectively.  (And yes, sometimes I 
will even provide an exception handler to deal with subrtracting 
Integer'First..)

-- 
                                           Robert I. Eachus

"The only thing necessary for the triumph of evil is for good men to do 
nothing." --Edmund Burke