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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!SIERRA.STANFORD.EDU!Bryan
From: Bryan@SIERRA.STANFORD.EDU (Doug Bryan)
Newsgroups: net.lang.ada
Subject: Re: Standard."="
Message-ID: <12244046924.13.BRYAN@Sierra.Stanford.EDU>
Date: Sat, 4-Oct-86 03:58:33 EDT
Article-I.D.: Sierra.12244046924.13.BRYAN
Posted: Sat Oct  4 03:58:33 1986
Date-Received: Mon, 6-Oct-86 18:20:46 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
List-Id: <comp.lang.ada>


The problem Jan Kok and Pat Rogers are discussing concerning where
the "predefined" operators are defined can be some what simplified 
using the following example:

	package P is
	   type T is (A, B, C);
	end P;

	package body P is
	   X  : constant T := A;
	   B1 : Boolean := X = C;
	   B2 : Boolean := P."=" (X, C);
	   B3 : Boolean := Standard."=" (X, C);
	   B4 : Boolean := Standard.P."=" (X, C);
	end P;

The question is, which of the initialization expressions for the Boolean
objects are valid?

Jan Kok writes:
>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.

The missunderstanding here is with "predefined".  It is sometimes
incorrectly interpreted to mean "defined immediately within package Standard"
when refering to operators.  The operations of the type T above are not 
sitting in Standard, waiting, even before the package P is compiled.
"Predefined" is more like "implicitly defined" when talking about
operators.  In chapters 1 and 2 of the RM, "predefined" does refer to
the outer-most scope, Standard, but in chapter 3 it takes on a slightly
different meaning:

3.3.3(2)
	"The remaining operations are each implicitly declared for a given
	 type declaration, immediately after the type definition.  These
	 implicitly declared operations comprise the basic operations,
	 the predefined operators (see 4.5), and enumerations literals."

Thus, if the implicit, predefined operations were made explicit, the spec
of P would look like:

	package P is
	   type T is (A, B, C);

	   function A return T;
	   function B return T;
	   function C return T;

	   function "="  (Left, Right : T) return Boolean;
	   function "/=" (Left, Right : T) return Boolean;
	   function "<=" (Left, Right : T) return Boolean;
	   function ">=" (Left, Right : T) return Boolean;
	   function "<"  (Left, Right : T) return Boolean;
	   function ">"  (Left, Right : T) return Boolean;
	end P;

RM 4.1.3 (13 .. 15), 8.2, 8.3, 8.6, and 8.7 takes care of the rest.  The
initializations of B1, B2 and B4 are valid; the initialization of B3 is 
invalid.  There is no function in Standard which looks like 

	   function "="  (Left, Right : T) return Boolean;

The exception to the rule is multiplication operations for fixed point
types...  but that's another story for another day...

doug
-------