Version 1.2 of acs/ac-00002.txt

Unformatted version of acs/ac-00002.txt version 1.2
Other versions for file acs/ac-00002.txt

!standard 03.05.04 (09)          00-12-02 AC95-00002/01
!standard 03.05.07 (11)
!standard 03.05.09 (14)
!standard 03.05.09 (16)
!class uninteresting 00-12-02
!status received 00-12-02
!subject The conversions implicit in numeric type conversions do not cause freezing
!summary
The conversions mentioned in 3.5.4(9) (for signed integer type definitions), 3.5.7(11) (for floating point definitions), 3.5.9(14) (for ordinary fixed point definitions), and 3.5.9(16) (for decimal fixed point definitions) are not implicit subtype conversions in the sense of 4.6(59-60), as they do not occur during overload resolution. Therefore, they do not trigger 13.14(8.2/1), and the types are not frozen by these conversions.
The index of the standard is incorrect when it calls these "implicit subtype conversions".
!appendix

From: Ivan B. Cvar
Sent: Thursday, November 30, 2000 11:46 AM

!topic Real_Range_Specification Freezes the Real Type Itself
!reference RM95-13.14(10)
!from Ivan B. Cvar 00-11-30
!keywords real_range_specification freezing conversion AI95-00106
!discussion


RM95 3.5.7(8) and 3.5.9(16) say that the bounds of a
real_range_specification are implicitly converted to the type being
defined.  But RM95 13.14(8,10) say that a static expression freezes both
its type and its subtype.  I'd guess RM95 13.14(10) should make another
exception for this case, but it doesn't.

This means that a type's real_range_specification freezes the type itself!
This seems very wrong.

package Example is
  Pi                : constant := 3.141_592_653_589_793;
  Radians_In_Circle : constant := 2.0 * Pi;

  type Angle   is digits 15    range -Radians_In_Circle .. Radians_In_Circle;
  type REG_FIX is delta  0.001 range -Radians_In_Circle .. Radians_In_Circle;

  for Angle'size   use 64;  -- LEGAL or NO?    -- see RM95 13.1(9)
  for REG_FIX'size use 64;  -- LEGAL or NO?    -- see RM95 13.1(9)
end;

BTW, the Technical Corrigendum 1 doesn't fix this problem which is somewhat
related to AI95-00106.


****************************************************************

From: Robert Dewar
Sent: Thursday, November 30, 2000 12:04 PM

this example is most certainly legal. If the RM says otherwise, it
is simply wrong (I am talking about the package Example previously given).

****************************************************************

From: Randy Brukardt
Sent: Thursday, November 30, 2000 12:15 PM

I think everyone agrees with this. The question is whether the RM (as
corrected by TC1) is wrong.

****************************************************************

From: Gary Dismukes
Sent: Thursday, November 30, 2000 12:17 PM

> RM95 3.5.7(8) and 3.5.9(16) say that the bounds of a
> real_range_specification are implicitly converted to the type being
> defined.  But RM95 13.14(8,10) say that a static expression freezes both
> its type and its subtype.  I'd guess RM95 13.14(10) should make another
> exception for this case, but it doesn't.
>
> This means that a type's real_range_specification freezes the type itself!
> This seems very wrong.

That's not right.  While the range expressions are implicitly converted
to the type, the expressions themselves are of some other type (in your
example they're of type universal_real), so they freeze that type, not
the new type being defined.

****************************************************************

From: Randy Brukardt
Sent: Thursday, November 30, 2000 1:22 PM

> RM95 3.5.7(8) and 3.5.9(16) say that the bounds of a
> real_range_specification are implicitly converted to the type being
> defined.

You mean 3.5.7(11). It says in part:

  If a real_range_specification is given, then the subtype is constrained to
  a range whose bounds are given by a conversion of the values of the
  simple_expressions of the real_range_specification to the type being
  defined.

The AARM indexes this under "implicit subtype conversion". 3.5.9(16) is
similar.

> But RM95 13.14(8,10) say that a static expression freezes both
> its type and its subtype.

13.14(8/1) says (in part, this part is not changed by the Corrigendum):

   A static expression causes freezing where it occurs.

That clearly applies here (real_range_specification's bounds are defined to
be static_simple_expressions, see 3.5.7(3)).

13.14(10) says:

   At the place where an expression causes freezing, the type of the expression
   is frozen, unless the expression is an enumeration literal used as a
   discrete_choice of the array_aggregate of an
   enumeration_representation_clause.

Thus the type is frozen. Oops!

Note that the corrigendum adds 13.14(8.2/1):

   If an expression is implicitly converted to a type or subtype T, then at
   the place where the expression causes freezing, T is frozen.

but that isn't really the problem here. (It is intended to handle
expressions which contain implicit conversions which are not the ultimate
type of the expressions).

> This means that a type's real_range_specification freezes the
> type itself! This seems very wrong.

Yes, that seems to be clearly the case.

Note that signed_integer_type_definitions have the same problem; see RM
3.5.4(3) & 3.5.4(9).

Thus we conclude that all representation items are illegal on all
user-defined signed integer, float, and fixed point types. :-) I think we
can all agree that this is a bogus result. I'll write up an AI for it.

However, I'm not sure what an appropriate fix is. Should we simply add
signed_integer_type_definition and real_range_specification to the "unless"
part of 13.14(10)?

****************************************************************

From: Tucker Taft
Sent: Thursday, November 30, 2000 2:17 PM

Randy Brukardt wrote:
> ...
>
> Thus we conclude that all representation items are illegal on all
> user-defined signed integer, float, and fixed point types. :-) I think we
> can all agree that this is a bogus result. I'll write up an AI for it.

Don't bother.  There is no problem.  The type of the static expressions
is not the same as the newly created type.

[For more details, see the other responses from me and Gary.]

****************************************************************

From: Tucker Taft
Sent: Thursday, November 30, 2000 12:27 PM

The conversion happens after overload resolution in this case.
The static expression is *not* of the new type (it can't be, since
the type doesn't exist yet).  The value is converted to the new type, that
is true, but that does not change the fact that the actual "static expression"
is not of this new type.  The freezing rules have to do with the
characteristics of constructs that appear in the source, not on the
semantic actions that take place as a result of the constructs.

****************************************************************

From: Robert Dewar
Sent: Thursday, November 30, 2000 1:38 PM

I agree with this analysis (though one must say that it should be entered
in the "angels-dancing-on-a-pin" contest :-)

****************************************************************

From: Randy Brukardt
Sent: Thursday, November 30, 2000 6:46 PM

Humm, doesn't the implicit conversion trigger the AI-106 (and TC) rule in
this case? To wit (13.14(8.2/1)):

   If an expression is implicitly converted to a type or subtype T, then at
   the place where the expression causes freezing, T is frozen.

If so, then we still have the problem. It certainly seems like it ought to;
the expression may not have the new type, but the implicit conversion sure
does. And this rule was written specifically to catch similar cases in
expressions (but certainly not in types).

Robert said:
>I agree with this analysis (though one must say that it should be entered
>in the "angels-dancing-on-a-pin" contest :-)

Certainly it sounds that way to me. Except that AI-0106 seems to have taken
away the pin without paying any attention to what happened to the angels...

****************************************************************

From: Gary Dismukes
Sent: Thursday, November 30, 2000 6:06 PM

Tuck wrote:
>
> The conversion happens after overload resolution in this case.
> The static expression is *not* of the new type (it can't be, since
> the type doesn't exist yet).  The value is converted to the new type, that
> is true, but that does not change the fact that the actual "static expression"
> is not of this new type.  The freezing rules have to do with the
> characteristics of constructs that appear in the source, not on the
> semantic actions that take place as a result of the constructs.

However it seems that the TC has now introduced various cases
of freezing due to implicit actions (specifically implicit calls
and implicit conversions, as documented in AI-106).  In particular,
as Randy wrote:

> Note that the corrigendum adds 13.14(8.2/1):
>
>    If an expression is implicitly converted to a type or subtype T, then at
>    the place where the expression causes freezing, T is frozen.
>
> but that isn't really the problem here. (It is intended to handle
> expressions which contain implicit conversions which are not the ultimate
> type of the expressions).

Well, maybe that is a problem, if the conversions in floating-point
type declarations are properly categorized as implicit conversions.
This rule ostensibly applies to all implicit conversions, so how can
we argue that it doesn't affect these conversions?  As far as I can see,
13.14(8.2/1) is broken.  The principle that static semantic rules
(not to mention dynamic semantic rules ;-) do not affect legality
makes perfect sense, but then what do we make of this TC-revised
freezing rule that mentions implicit conversions?  It looks to me
like this rule should not be referring to implicit conversions, which
happen as part of other semantics, but somehow needs to refer
to resolution rules (expected type stuff).

****************************************************************

From: Robert Dewar
Sent: Thursday, November 30, 2000 7:22 PM

Why don't we give this the priority it deserves, which is very low, and
put it on the stack to worry about when there is nothing important to
worry about. I know, it is *so* tempting to indulge in entertaining wording
discussions :-)

****************************************************************

From: Tucker Taft
Sent: Thursday, November 30, 2000 10:32 PM

Randy Brukardt wrote:
>
> > The conversion happens after overload resolution in this case.
> > The static expression is *not* of the new type (it can't be, since
> > the type doesn't exist yet).  The value is converted to the new type, that
> > is true, but that does not change the fact that the actual "static
> > expression" is not of this new type.  The freezing rules have to do
> > with the characteristics of constructs that appear in the source, not
> > on the semantic actions that take place as a result of the constructs.
>
> Humm, doesn't the implicit conversion trigger the AI-106 (and TC) rule in
> this case?

There is no "implicit conversion" in the sense this
refers to.  The values are converted as part of the
*semantics* of the construct.  Implicit conversion
is something performed during overload resolution to
make an expression match its expected type.

> ... To wit (13.14(8.2/1)):
>
>    If an expression is implicitly converted to a type or subtype T, then at
>    the place where the expression causes freezing, T is frozen.
>
> If so, then we still have the problem. It certainly seems like it ought to;
> the expression may not have the new type, but the implicit conversion sure
> does.

Again, this is only if overload resolution is performing
the implicit conversion.  Here, the conversion is part
of the semantics, not the overload resolution.  If anything,
the expected type is "any real type" which is closest to
"universal_real" and the implicit conversion performed at
overload resolution time (which is the one that matters
for freezgin) occurring would be to universal_real, not to the
newly defined type.

> ... And this rule was written specifically to catch similar cases in
> expressions (but certainly not in types).
>
> Robert said:
> >I agree with this analysis (though one must say that it should be entered
> >in the "angels-dancing-on-a-pin" contest :-)
>
> Certainly it sounds that way to me. Except that AI-0106 seems to have taken
> away the pin without paying any attention to what happened to the angels...

I don't agree.  AI-106 doesn't apply.  There is no "implicit"
conversion here, which is a term that relates to something
happening during overload resolution.

****************************************************************

From: Randy Brukardt
Sent: Thursday, November 30, 2000 10:39 PM

Sounds like even *more* dancing on a pin.

Anyway, if this is correct, then the index of the ARM and AARM is wrong,
which includes paragraphs 3.5.4(9), 3.5.7(11), and 3.5.9(14, 16) under
"implicit subtype conversion". Luckily the index isn't normative. The index
points to a note in 4.6 (4.6(59-60)) as the definition of "implicit subtype
conversion". This note matches Tucker's description, but of course that
isn't normative either.

Looks like we have at least a presentation issue (if we agree with Tucker's
dancing here, then those index entries should be removed). Of course,
presentation issues are easy to resolve.

****************************************************************

From: Robert Dewar
Sent: Thursday, November 30, 2000 10:39 PM

What a horrible nightmare of terminological chaos

explicit conversions
implicit conversions

and now,

post-overload resolution conversions that are neither explicit nor implicit

UGGGH!

****************************************************************

Questions? Ask the ACAA Technical Agent