Incompatibility involving universal expressions

Incompatibility involving universal expressions

[jhassett]

I've run into an apparent Ada 83/Ada 95 incompatibility that
surprised me because it seems that it would be rather common, and
I haven't seen it documented (e.g., in Bill Taylor's Ada
Compatibility Guide).  The changes that cause the incompatibility
are apparently motivated by a desire to eliminate Beaujolais
effects (http://www.adahome.com/FAQ/programming.html#beaujolais).
I'm wondering if I've misunderstood the situation, and hoping
someone can set me straight if I have.

Here is an example:

with Text_IO;
package P is
  N : constant := 10;
  type T is new Text_IO.Count range 2 .. N - 1;
end P;

This compiles under the Rational VADS Ada 83 compiler, but not
under the Green Hills Ada 95 compiler ("Error: line 4 col 39
LRM:8.6(28), Expression has no possible interpretation as an
expression of the type Count, Continuing").  Maybe Green Hills (or
Rational) and I have both missed something, but here's my
understanding of the incompatibility:

In Ada 83, there are operators defined for type universal_integer
(RM83-4.10), so the expression "N - 1" is a universal expression,
yielding a universal_integer value.  Both the literal "2" and "N -
1" are implicitly converted (RM83-4.6(15)) to type Text_IO.Count,
which is the type required for the range constraint (RM83-3.5(4)).
Thus, the declaration of T is valid even though the "-" operator
for type Text_IO.Count is not directly visible.

In Ada 95, there are no operators defined for universal types
(RM95-3.4.1(7)), so the "universal expressions" of Ada 83 become
expressions of the corresponding root types, and "N - 1" is
interpreted as having type root_integer.  The Ada 83 rules about
implicit conversion of universal types are replaced by rules
allowing a construct to have a universal type when the expected
type is covered by the universal type (RM95-8.6(24) and
AARM95-8.6(34.b)).  But this doesn't allow an expression of
a root type to be accepted where a descendant is expected (see
AARM95-3.4.1(14a)), so when "N - 1" is interpreted as having type
root_integer, it is not acceptable.

There are several ways to fix the illegal declaration in Ada 95.
One is to make the "-" operator for type Text_IO.Count directly
visible, so that "N - 1" can be interpreted as having type
Text_IO.Count:

with Text_IO;
package P is
  use type Text_IO.Count;
  N : constant := 10;
  type T is new Text_IO.Count range 2 .. N - 1;
end P;


Another fix is to explicitly convert "N - 1":

  type T is new Text_IO.Count range 2 .. Text_IO.Count(N - 1);


The rules for number declarations specifically allow expressions
of any numeric type, though the named numbers themselves have
universal types, so this is also legal:

with Text_IO;
package P is
  N : constant := 10;
  K : constant := N - 1;
  type T is new Text_IO.Count range 2 .. K;
end P;


If I've got all this right, it seems that there would be lots of
contexts where Ada 83 universal expressions involving operators
become expressions having root types in Ada 95, and are not
accepted.  Is this as common as I think it is?


- Jim Hassett

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Incompatibility involving universal expressions

[jhassett]

Last week I posted a message about what I thought was an Ada 83/
Ada 95 incompatibility I'd run into, and asking if someone could
set me straight if I'd misunderstood the situation.

It seems that everyone who bothered to read my message was either
too busy or too kind to embarrass me with a response, so I'm
responding to myself, in case any reader might still be confused.

The incompatibility does not exist.  The details mainly concern
my creative misunderstanding of RM83.

I had complained that the following little package spec compiled
under the Rational VADS Ada 83 compiler, but not under the Green
Hills Ada 95 compiler:

with Text_IO;
package P is
  N : constant := 10;
  type T is new Text_IO.Count range 2 .. N - 1;
end P;

I'm now convinced that the VADS compiler was in error: the use of
"N - 1" above is illegal in both versions of Ada.  I had thought
that this expression could be implicitly converted from
universal_integer to Text_IO.Count in Ada 83, but not in Ada 95.
In fact, it cannot be implicitly converted in either language.

What I missed was a proper interpretation of this restriction from
RM83-4.6(15):

   An implicit conversion of an operand of type universal_integer
   to another integer type . . . can only be applied if the
   operand is either a numeric literal, a named number, or an
   attribute

In other words, more general universal_integer expressions such as
"N - 1" are not subject to implicit conversion.

I had read the paragraph containing the quoted restriction, but I
think I dismissed it with too narrow an interpretation of the word
"operand" (which doesn't seem to be defined in RM83).  Without much
thought, I took this to refer only to actual parameters of
subprograms, so I didn't see it as relevant to a bound of a range.
(It still isn't clear to me why the quoted restriction uses the
word "operand" instead of "expression".)

In any event, I'm happy to find that the supposed incompatibility
is not real, but I'm chagrined at having been so misled by a faulty
compiler.

- Jim Hassett

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Incompatibility involving universal expressions

[Tucker Taft]

jhassett@my-dejanews.com wrote:

: ...
: In any event, I'm happy to find that the supposed incompatibility
: is not real, but I'm chagrined at having been so misled by a faulty
: compiler.

Don't take it personally ;-).  Getting the visibility of operators
just right is tricky, especially given that most Ada compilers try
to avoid "polluting" the symbol table with vast numbers of
predefined operators.  

For what it is worth, my "favorite" operator overloading problem
is "aggregate & aggregate & aggregate & aggregate & ...".
There is an extremely nasty combinatorial explosion possible here if 
there are any array-of-composite types around, since the compiler
is not "allowed" to look "inside" an aggregate until it decides
what is its type.

In any case, I'm glad to hear that the Ada 95 Green Hills 
compiler did the right thing.  It uses my favorite Ada 95 
front end. ;-).

: - Jim Hassett

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company