Version 1.1.1.1 of ais/ai-00170.txt

Unformatted version of ais/ai-00170.txt version 1.1.1.1
Other versions for file ais/ai-00170.txt

!standard 13.03 (05)          97-03-19 AI95-00170/00
!class confirmation 96-11-16
!status received 96-11-16
!priority Low
!difficulty Easy
!subject Can an attribute defined in an annex be set in an attribute definition clause?
!summary 96-11-16
!question 96-11-16
!response 96-11-16
!appendix

!section 13.3(05)
!subject Can an attribute defined in an annex be set in an attribute definition clause?
!reference RM95-13.3(5)
!from Robert I. Eachus 9-10-21
!reference 96-5734.a Robert I. Eachus 96-10-21>>
!discussion

   This question is obviously not high-priority, but I think it is a
glitch.  Annex K is informative, and an implementation can conform to
the core excluding the annexes.  So I suspect that an implementation
that accepted attributed definition clauses for P'Body_Version,
E'Caller, T'Identity, or P'Version is conforming, but the attributes
in Annex A are out of bounds.  (J.9 has T'Storage_Size, with an
explicit permission.)

   I said:

   >    They did.  First look at 'Machine_Overflows.  It is perfectly
   >legal for even Float'Machine_Overflows to be false and the
   >implementation to return, say IEEE nonsignaling NaNs in such a case.
   >Also RM95 3.5.5(26) and 3.5.6(8) allow for nonstandard integer and
   >real types respectively, and mention saturation types as one possible
   >use for the feature.

   Marin David Condic said:

   > Interesting. I looked it up in The Green Book for Ada83 and my
   > problem with it is this: It tells you what the implementation
   > does, but doesn't let you select the behavior you want. So if
   > you're lucky enough to get a sympathetic implementation - or you
   > don't need it "both ways" depending on usage, you might be O.K.
   > with this. It also doesn't say that the result saturates - only
   > that you'll either get an exception or not.

   Interesting question for the ARG.  I think that an implementation
that allowed setting 'Machine_Overflows by a representation clause
would be illegal, but is this true for all attributes defined in the
annexes?  (The 'Machine_Overflows question is probably academic, since
any compiler supporting the capability would probably do it by
providing two predefined types with the same 'Digits.  But there are
other attributes found both in A and in the optional annexes for which
the question is interesting.)

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

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

!section 13.3(05)
!subject Can an attribute defined in an annex be set in an attribute definition clause?
!reference AI95-00170/00
!from Keith Thompson 96-11-19
!reference 96-5760.b Keith Thompson 96-11-19>>
!discussion

Robert Eachus writes:

    (The 'Machine_Overflows question is probably academic, since any
    compiler supporting the capability would probably do it by providing
    two predefined types with the same 'Digits.  But there are other
    attributes found both in A and in the optional annexes for which
    the question is interesting.)

Actually, it could be more than academic.  A good way to support user
control of 'Machine_Overflows could be to provide multiple predefined
types with the same 'Digits and different 'Machine_Overflows, and
then allow the attribute to be specified for a user-defined type.
Otherwise user control of the attribute would be limited to explicit
references to predefined types.

For example:

    -- Two predefined types:
    -- type Fast_Float is digits 6; -- 'Machine_Overflows = False
    -- type Safe_Float is digits 6; -- 'Machine_Overflows = True

    -- Two user-defined types:
    type My_Fast_Float is digits 6;
    for My_Fast_Float'Machine_Overflows use False;
    -- Implicitly derived from Fast_Float

    type My_Safe_Float is digits 6;
    for My_Safe_Float'Machine_Overflows use True;
    -- Implicitly derived from Safe_Float


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

!section 13.3(05)
!subject Can an attribute defined in an annex be set in an attribute definition clause?
!reference AI95-00170/00
!reference 96-5760.b Keith Thompson 96-11-19
!from Bob Duff
!reference 96-5762.b Robert A Duff 96-11-20>>
!discussion

>     -- Two user-defined types:
>     type My_Fast_Float is digits 6;
>     for My_Fast_Float'Machine_Overflows use False;
>     -- Implicitly derived from Fast_Float
> 
>     type My_Safe_Float is digits 6;
>     for My_Safe_Float'Machine_Overflows use True;
>     -- Implicitly derived from Safe_Float

This is Ada-83-think.  In Ada 95, user-defined floating point types are
derived from root_real.  The predefined ones in standard are not
special.  In fact, an implementation can support "type My_Float is
digits 100;" despite the fact that there is no named predefined type
with that many digits; this was not true in Ada 83.

Nonetheless, your point is clear -- it would be useful to allow
user-specified 'Machine_Overflows.  However, the intent was to disallow
that, for portability.  The intent is that if the implementation wants
to do something different from the standard thing, it should use a
different attribute name.

- Bob


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

Questions? Ask the ACAA Technical Agent