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: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Equality operator overloading in ADA 83
Date: 1997/04/26
Message-ID: <dewar.862054383@merv>#1/1
X-Deja-AN: 237504271
References: <01bc4e9b$ac0e7fa0$72041dc2@lightning>
 <mheaney-ya023680002204970006190001@news.ni.net>
 <335CAEFE.35DC@elca-matrix.ch> <dewar.861864029@merv>
 <E9588B.FsE@world.std.com> <dewar.861970467@merv>
 <mheaney-ya023680002504972023370001@news.ni.net>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-04-26T00:00:00+00:00
List-Id: <comp.lang.ada>


<<Right now, the RM95 is silent about whether equality composes for
Bounded_String.  The requirement for composability is therefore ambiguous,
which isn't acceptable for any kind of requirements document.>>

The RM leaves many aspects of Ada as implementation defined. There is no
general principle that this is unacceptable. Indeed, trying to remove all
implementation dependencies as Java does is an efficiency disaster -- for
example in the Java case, the requirement for IEEE fpt leads to completely
unaceptable performance on some targets (such as SGI and Alpha), but
in practice no one takes these specs that seriously.

In the Ada world, we prefer to have the spec taken seriously, and explicitily
recognize the implementation dependencies.

So there is no general principle here, other than the general one which
says don't make things impl-dependent unless there is a good reason. So
the question is whether there is a good reason here. Obviously the ARG
on reflection feels that it is better that this not be impl dependent,
but there is a cost -- in the case of bounded string, either there
will be a non-zero efficiency cost at runtime for ALL operatoins on
bounded strings ALL the time, or you need a very special non-Ada kludge
in the compiler -- and we don't like to require these.

I note that very often people assume that because the GNAT library is
written in Ada 95, it can be used with any Ada 95 compiler. In particular
for instance, I often meet people who have been told by sales people for
other compilers not to worry about the informatoin systems annex, since
you can just use the GNAT libraries.

Well this of course is NOT always true, and in particular is not true
at all of the informatoin systems annex stuff (since this requires
fundamentall support from the compiler for high precision deciaml fixed
point which at present only exists in GNAT, and also recognition of
some intrinsics (e.g. the one for DIVIDE).

Well up to now the bounded string implementation has indeed been portable
(I know for example that Aonix has distributed GNAT sources for some of
the library functions for Object Ada, which is perfectly fine, although
they tend necessarily to be out of date versions -- I don't know if
bounded string is such a package).

Now with the version of GNAT in which this problem is "fixed", you will
have to add bounded strings to the list of GNAT packages that are GNAT
specific. No big deal, and certainly not a disadvantage for us, but 
something we like to avoid where possible.

Robert Dewar
Ada Core Technologis