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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,c3a7c1845ec5caf9
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Equality operator overloading in ADA 83
Date: 1997/04/24
Message-ID: <E95I0t.J45@world.std.com>#1/1
X-Deja-AN: 237068276
References: <01bc4e9b$ac0e7fa0$72041dc2@lightning>
 <mheaney-ya023680002204972109430001@news.ni.net>
 <335E0B1F.12C9@elca-matrix.ch> <dewar.861851658@merv>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 1997-04-24T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <dewar.861851658@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>It is helpful if you make clear whether you are making a pronouncement about
>the original Ada 83 design or the decision not to introduce upwards
>incompatibilities in the Ada 95 redesign (I trust you are NOT making a 
>statement about Ada 95 implementations :-)

It would also be helpful to know whether you are talking about just
equality, or all operators, or just composite types, or what.  (E.g.,
should redefining "<" on T cause array-of-T's "<" to change?)  It's not
easy to know where to draw the line.

- Bob