Version 1.6 of ais/ai-00170.txt

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

!standard 13.03 (05)          99-07-27 AI95-00170/02
!class confirmation 96-11-16
!status WG9 approved 99-06-12
!status ARG Approved (with changes) 8-0-1 99-03-24
!status work item 98-10-15
!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
An attribute defined in an annex cannot be set in an attribute definition clause, unless the Reference Manual explicitly allows it.
!question
Consider an attribute, attribute defined in an annex but not explicitly stated to be a user-specifiable attribute (Partition_Id, for example). Can an implementation support an attribute definition clause for such an attribute? (No.)
!response
13.3(5) says that:
"An attribute_designator is allowed in an attribute_definition_clause only if this International Standard explicitly allows it, or for an implementation defined attribute if the implementation allows it. [...]"
1.1.2 (14) says that:
"The core language and the Specialized Needs Annexes are normative, [...]"
Therefore, the legality rule in 13.3(5) clearly applies to annexes as well as to the core language.
!ACATS test
It would be possible to create B-Tests to try to set some of these attributes, but it would be of little value - implementations are unlikely to implement such things accidentally.
!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

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

From: 	Robert Dewar[SMTP:dewar@gnat.com]
Sent: 	Thursday, October 15, 1998 6:30 AM
Subject: 	Re: AI-170

there is a mismatch of intents here. The question is all about the utility
of allowing a user to specify Machine_Overflows, not about the syntax to be
used in doing it.

THe utility question is an interesting one, and the question is whether to
revisit the design decision.

Right now, no compiler I know of allows this to be user specifiable, so
worrying hard about making sure that the specification of this, if it
*were* allowed would be portable between compilers that *did* allow it
seems a complete waste of time to me.

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

From: 	Robert A Duff[SMTP:bobduff@world.std.com]
Sent: 	Thursday, October 15, 1998 9:22 PM
Subject: 	Re: AI-170

Robert says:

> Right now, no compiler I know of allows this to be user specifiable, so
> worrying hard about making sure that the specification of this, if it
> *were* allowed would be portable between compilers that *did* allow it
> seems a complete waste of time to me.

I agree -- it's a waste of time to worry about things that make no
difference in practise.

I think that instead of assigning somebody to write up this AI, and then
voting on it, the ARG should decide to classify it as !No Action, and be
done with it.

- Bob

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


Questions? Ask the ACAA Technical Agent