Re: Equality operator overloading in ADA 83

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Matthew said

<<Robert, you're being a wee bit pedantic, don't you think?  We simply need
to specify the _external_ behavior of type Bounded_String, specifically the
behavior of equality, under _all_ circumstances, including those times when
predefined operators re-emerge.  No one is suggesting we publically specify
the any aspects of the _representation_ of Bounded_String.

Perhaps the real issue is, What does "representation" mean?  You assume
equality is a representation issue, others assume equality is not a
representation issue (ie is external behavior).  So let's resolve _that_
ambiguity
>>


Well first of all, the exhortation to resolve that ambiguity is like a
coach arriving half an hour after his team has won the championship, and
exhorting them to win -- this *particular* issue is already decided by
an extension to the language.

I do not at all "assume that equality is a reprsentatoin issue", what makes
you think this? I was reacting to your general claim that it is necessary
that the RM specify all aspects of the interface for the annex A packages.
You seemed to be arguing:

"we must specify the behavior of equality, because we must specify all
such behavior"

If I misread you, then my comment does not apply. The point is that the
RM as it stands leaves it implementation dependent whether or not bounded
string equality applies. There are lots of other things it leaves impl
dependent. The mere fact that something is left impl dependent is not of
itself bad.

In a particular instance, it may be a mistake, and, as you see, the ARG is
in the business of addressing specific mistakes. I do not argue that equality
for bounded string should be left impl dependent (if you check the minutes
of the Maple Syrup meeting of the ARG, you will find that I voted for this
AI :-)