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,829936167b39e478
X-Google-Attributes: gid103376,public
From: stt@houdini.camb.inmet.com (Tucker Taft)
Subject: Re: Incompatibility involving universal expressions
Date: 1998/10/12
Message-ID: <F0q2G5.GqM.0.-s@inmet.camb.inmet.com>#1/1
X-Deja-AN: 400296608
Sender: news@inmet.camb.inmet.com (USENET news)
X-Nntp-Posting-Host: houdini.camb.inmet.com
References: <6vt19c$2iq$1@nnrp1.dejanews.com>
Organization: Intermetrics, Inc.
Newsgroups: comp.lang.ada
Date: 1998-10-12T00:00:00+00:00
List-Id: <comp.lang.ada>

jhassett@my-dejanews.com wrote:

: ...
: In any event, I'm happy to find that the supposed incompatibility
: is not real, but I'm chagrined at having been so misled by a faulty
: compiler.

Don't take it personally ;-).  Getting the visibility of operators
just right is tricky, especially given that most Ada compilers try
to avoid "polluting" the symbol table with vast numbers of
predefined operators.  

For what it is worth, my "favorite" operator overloading problem
is "aggregate & aggregate & aggregate & aggregate & ...".
There is an extremely nasty combinatorial explosion possible here if 
there are any array-of-composite types around, since the compiler
is not "allowed" to look "inside" an aggregate until it decides
what is its type.

In any case, I'm glad to hear that the Ada 95 Green Hills 
compiler did the right thing.  It uses my favorite Ada 95 
front end. ;-).

: - Jim Hassett

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company