comp.lang.ada
 help / color / mirror / Atom feed
* Type conversion from Universal Integer
@ 1993-03-03 22:48 R. Muralidhar
  1993-03-04 13:12 ` Dave Collard x7468
  0 siblings, 1 reply; 2+ messages in thread
From: R. Muralidhar @ 1993-03-03 22:48 UTC (permalink / raw)



Hi,

I have the following piece of code

 -------------------------------------------------------------------------
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.

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.

Any help in explaining this situation will be greatly appreciated.

Thanks in advance.


                 _
  /|/), , ;_ _  // .
(/  /(_<_/ '(_(_X_<_
murali@saifr00.cfsat.honeywell.com

Muralidhar Rajappa
Honeywell Commercial Flight Systems Group
Phoenix AZ
-- 
                 _
  /|/), , ;_ _  // .
(/  /(_<_/ '(_(_X_<_
murali@saifr00.cfsat.honeywell.com



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Type conversion from Universal Integer
  1993-03-03 22:48 Type conversion from Universal Integer R. Muralidhar
@ 1993-03-04 13:12 ` Dave Collard x7468
  0 siblings, 0 replies; 2+ messages in thread
From: Dave Collard x7468 @ 1993-03-04 13:12 UTC (permalink / raw)


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



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1993-03-04 13:12 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1993-03-03 22:48 Type conversion from Universal Integer R. Muralidhar
1993-03-04 13:12 ` Dave Collard x7468

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox