The equals function.

The equals function.

[Roger Racine]

The problem, according to Pat Rogers is:
<Dear Ada language-lawyers,
<
<Here's a question:
[I deleted a discussion of a possible recursion problem that he 
wants to avoid]
<Now the question: suppose that LP is actually an access type, rather than 
<derived from Integer. So,
<
<
<    package P is
<
<      type LP is limited private;
<
<      function "="( Left, Right : LP ) return Boolean;
<
<    private
<
<      type LP is access Integer;  -- or access whatever
<
<    end P;
<
<
<In the body, the above approach cannot be used, since there is no 
<conversion or qualification type available. To wit,
<
<    package body P is
<
<      function "="( Left, Right : LP ) return Boolean is
<      begin
<    	if Left = null then ...
<
<This is a recursive call to P."=" on my compiler (yes, validated).
<
<
<
<One could simply do the following (my current approach), 
<
<    begin
<      return Left.all = Right.all;  -- null pointer dereference possible
<    exception
<      when Constraint_Error =>  
<        return False;
<    end "=";
<
<However, in some situations it may be desirable to check for the null
<value rather than relying on Constraint_Error (which might be suppressed later
<by another programmer, etc... ). Maybe it is just correct in some particular
<application to have two objects of type LP be equal if they are both null. 
<
<In those cases, what can be done ?
<
<Is the compiler correct ?   I've not had time to check it on some others.
<
<Any suggestions will be appreciated.
<
<Thanks !
<

This actually is a more interesting problem than I thought at first.
People tend to like the "infix" notation for operators. They never think
about using the fully qualified name. Therefore, I thought that all that
was needed was:

      if STANDARD."="(LEFT, null) then

Unfortunately, the equality operator is not found in package STANDARD!
Appendix C of the reference manual states:
     This annex outlines the specification of the package STANDARD
     containing all predefined identifiers in the language.
This seems to say that the equality operator should be there. But it is not
there.

Section 8.6 states:
     The predefined types (for example the types BOOLEAN, CHARACTER
     and INTEGER) are the types that are declared in a predefined
     package called STANDARD; this package also includes the 
     declarations of their predefined operations. The package STANDARD
     is described in Annex C. Apart from the predefined numeric types,
     the specification of the package STANDARD must be the same for all
     implementations of the language.

Since an access type (and array types and record types) are not predefined
types (as opposed to INTEGER, et al), this would seem to allow for those
equality operators to be missing. In fact, since the specification "must
be the same" as the Annex C spec., they would seem to be required to be 
missing. WHERE ARE THEY DECLARED?

I checked with two validated compilers, and both rejected the STANDARD."="
approach.

Roger Racine
C.S. Draper Lab.
-------

Re: The equals function.

[Jan Kok]

In article <8609252153.AA03089@ucbvax.Berkeley.EDU> RRACINE@ADA20.ISI.EDU (Roger Racine) writes:
>The problem, according to Pat Rogers is:
My summary: declaring an "=" operator for a limited private type which
            is actually 'access INTEGER' leads to a recursive call of this "=".
Roger answers correctly:
>                    all that was needed was:
>
>      if STANDARD."="(LEFT, null) then
>
My summary: qualify the operator (in prefix notation) instead of try to
            help the overloading resolution algorithm by qualifying the
            operands.
I ignore other helpful answers which avoid the interesting problem, like:
   Introduce a hidden type for the 'access INTEGER' type.

But then Roger adds:
>Unfortunately, the equality operator is not found in package STANDARD!

He quotes App. C and section 8.6 of the ARM to support this, and ends with

>I checked with two validated compilers, and both rejected the STANDARD."="
>approach.

That's the interesting part (to me).
I checked with a validated compiler (wellll, expired now), and it
recognizes STANDARD."=".
So the match is still open, but the problem should not be settled
by a democratic check on all validated compilers of course.

I tend to accept what the compiler I can use does, and my attempt of an
explanation is:
1. According to ARM 4.5.2, "=" is predefined.
2. App. C does not contain, and does not pretend to contain all
   specifications of predefined operators. It contains a lot of comments.
   The package STANDARD in App C contains, as it says it should:
      the type declarations for the predefined types, together with
      some subtypes and packages.
   It says that the predefined operators are IMPLICIT. This applies
   to operators for 'any type' like "=" as well as those for the predefined
   types.
3. The missing link is:
   Where does the manual say that STANDARD is the appropriate prefix
   for the full name of the implicit operators.
   I would say: if Roger's two validated compilers accept STANDARD."+",
   they should accept STANDARD."=" as a matter of consequence.

Re: The equals function.

[Jan Kok]

CORRECTION
I must apologize about my previous posting, the subject of the existence
of the operator STANDARD."=" has been too difficult for me. I maintain
that it is interesting, at least I learned something.

I wrote:
In article <310@zuring.mcvax.UUCP> jankok@zuring.UUCP (Jan Kok) :
>
>I checked with a validated compiler (wellll, expired now), and it
>recognizes STANDARD."=".

But my test was too simple. I checked whether it recognized STANDARD."="
for operands of a predefined type like FLOAT. It does.
But my compiler does not accept STANDARD."=" for operands of a
user-defined type like 'access INTEGER'.

With help of a colleague, I may offer a better explanation: for a new
type, the prefix in the expanded name should be that of the module
(package, etc.) containing the type declaration. So, there is no
disagreement among validated compilers about this issue, as far as
tests have been made now by net-readers.

The person with the original problem is not helped by this. The prefix
can be used if the new definition and the "=" used in the call are
(possibly implicitly) declared in different modules.
-- 
Mail: Jan Kok, CWI (afd. NW), Postbus 4079, NL-1009 AB Amsterdam, Nederland
UUCP: {seismo, decvax, philabs, okstate, garfield}!mcvax!zuring!jankok
---------------------------------------------------------------
   One of the Warner Bros to Albert Einstein:
      I have a theory about relatives myself : Don't hire them!

Re: The equals function.

[BBardin]

In response to your question "Where are the predefined operations for
array, access and record types defined if not in package 'Standard':

I think the answer follows from the realization that the predefined
types 'Integer', 'Characer' and 'Boolean' are quite different things
than array, record and access types.  The later are classes (or types)
of types, while the former are instances of Ada type classes.
i.e., The predefined type 'Integer' is just one instance of all possible
integer types, while 'Boolean' and 'Character' are predefined 
enumeration types (enumeration being the class).   

ARM 3.3.3(2) states that the predefined operations for a type (not a
type class) occur after the type declaration (an instance of the
class).  The predefined operations for 'Integer', 'Character' and
'Boolean' are found in 'Standard' because that is where the type
declarations for these types are found.  There are no predefined
operations for 'array', 'record', and 'access' qua type classes, only
for actual array, record and access types.

Note that 'String' is a predefined array type, (just as 'Integer' is a
predefined integer type) and the predefined operations for 'String'
are found immediately following the declaration in package 'Standard'.
Note also that the term 'integer' has been overloaded to refer to both
a class of types (as in "... 'Short_Integer' is an integer type ...")
and a specific instance of a type (as in "... the predefined type
'Integer' ...").

I hope this has been of some help,

John Prentice,
GMHEC
-------