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
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,666c6fe65641ecc0
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1993-03-04 05:21:29 PST
Newsgroups: comp.lang.ada
Path: 
 sparky!uunet!caen!saimiri.primate.wisc.edu!aplcen.apl.jhu.edu!ddsdx2.jhuapl.edu!dlc
From: dlc@ddsdx2.jhuapl.edu (Dave Collard x7468)
Subject: Re: Type conversion from Universal Integer
Message-ID: <1993Mar4.131222.871@aplcen.apl.jhu.edu>
Sender: news@aplcen.apl.jhu.edu (USENET News System)
Organization: Johns Hopkins University
References: <1993Mar3.224845.18874@saifr00.cfsat.honeywell.com>
Distribution: usa
Date: Thu, 4 Mar 93 13:12:22 GMT
Date: 1993-03-04T13:12:22+00:00
List-Id: <comp.lang.ada>

In <1993Mar3.224845.18874@saifr00.cfsat.honeywell.com> murali@saifr00.cfsat.honeywell.com (R. Muralidhar) writes:
> -------------------------------------------------------------------------
>package P is
>  type A is range 1 .. 10;
>  type Array_Constrained_Type is array ( A range <> ) of Integer;
>end P;

>with P;
>procedure test is 

> Const : constant := 5;
> type Local_A is range 1 .. 10;

> type Local_Array_Constrained_Type is array ( Local_A range <> ) of Integer;

> subtype Array_type1 is P.Array_Constrained_Type(1 .. (const/2)); -- Line A
> subtype Array_type2 is P.Array_Constrained_Type(1 .. P."/"(const,2)); -- Line B
> subtype Array_type3 is Local_Array_Constrained_Type(1 .. (const/2)); -- Line C

>begin
>  null;
>end test;
> -------------------------------------------------------------------------

> detect an error on DEC Ada compiler, in the line marked "Line A", saying:

>%ADAC-E-RESTYPINCON, (1) Result type of expression is inconsistent with its  
>        context, which requires integer type A in P at line 2 [LRM 8.7] 

>But the same piece of code compiled fine under Verdix Ada Compiler on Sun.
no comment.

>Line B compiled fine in both compilers, so did Line C.

>Am I dealing here with some interpretation of a language feature that is
>implementation dependent? Or is it that one or the other compiler is wrong?


>Also, LRM 4.6(15) says that "An implicit conversion of an operand of
>universal integer to another integer type, ..., can only be applied if the
>operand is either a numeric literal, a named number, or an attribute;"

>I take it that the compiler tries to implicitly convert to the integer type A,
>the upper and lower bounds of the specified ranges in all three lines, 
>Line A, Line B, and Line C. Since (const/2) is an expression and is not a
>numeric literal, not a named number, and not an attribute, the compiler(s)
>should have detected errors in all three lines.

Ah, but Const IS a named number and 2 is a numeric literal, so,
  In line B, Const and 2 are converted to type P.A because the only P."/" available
  that matches the required return type (P.A) is the inherited division operator
  for type P.A.

  In line C the same thing is true except replace P.A with Local_A.

  Now Line A.  The expression (const/2) MUST evaluate to type P.A.  The only 
  division operator available that returns P.A is the one inherited in package
  P when the type A was derived.  That operation is not visible (as you did not
  use P).  Therefore, no division operator is visible which returns type P.A.
  The DEC compiler is correct (as usual).


--Thor
collard@capsrv.jhuapl.edu
dlc@ddsdx2.jhuapl.edu