From dewar@gnat.cs.nyu.edu Tue Oct 25 00:36:16 1994
Return-Path:
Received: from gnat.cs.nyu.edu by dsd.camb.inmet.com (4.1/SMI-4.1)
id AA08877; Tue, 25 Oct 94 00:36:16 EDT
Received: by gnat.cs.nyu.edu (5.61/1.34)
id AA10903; Tue, 25 Oct 94 00:36:11 -0400
Date: Tue, 25 Oct 94 00:36:11 -0400
From: dewar@gnat.cs.nyu.edu (Robert Dewar)
Message-Id: <9410250436.AA10903@gnat.cs.nyu.edu>
To: ada9xmrt@dsd.camb.inmet.com
Subject: Re: 94.1024 ada9x-mrt mail messages
!topic Legality of Potentially Static Expressions
!reference RM9X-4.9(2,33,34);5.0
!reference 94-4484.a Robert Dewar 94-07-09
!reference 94-4841.a Erhard Ploedereder 94-10-09
!reference 94-4926.a Tucker Taft 94-10-24>>
!from Robert Dewar 94-10-25
<>
!discussion
Can't we go a step further and eliminate the term potentially static,
replacing it with simply static.
The rule is then that static expressions are evaluated at compile time
unless .. short-circuit ...
and if a static expression that is evaluated at compile time fails a
language defined check, then that is illegal.
I think that works fine, you really don't need the distinction between
static expressions and potentially static expressions any more.
FOr example, in
X : constant := yyy;
we say that yyy must be static. We mean that it must be (in the old language)
potentially static. The other rules say that yyy is evaluated, and must not
raise a language defined check.
From barnes@alsys.co.uk Tue Oct 25 06:18:27 1994
Return-Path:
Received: from eros.britain.eu.net by dsd.camb.inmet.com (4.1/SMI-4.1)
id AA25997; Tue, 25 Oct 94 06:18:27 EDT
Received: from alsys.co.uk by eros.britain.eu.net with UUCP
id ; Tue, 25 Oct 1994 10:14:34 +0000
Received: by alsys.alsys.co.uk (4.1/SMI-4.1.1) id AA29576;
Tue, 25 Oct 94 09:54:19 GMT
Date: Tue, 25 Oct 94 09:54:19 GMT
From: barnes@alsys.co.uk (John Barnes)
Message-Id: <9410250954.AA29576@alsys.alsys.co.uk>
To: bertier@alsys.fr
Cc: ada9xmrt@dsd.camb.inmet.com
In-Reply-To: Antoine Bertier's message of Mon, 24 Oct 1994 09:44:05 --100 <9410240844.AA17036@altair.alsys_sa>
Subject: package syntax is awful .. zombic
!topic package syntax is awful .. zombic
!reference RM9X-7.1;5.0
!reference 94-4911.a John Barnes 94-10-19
!reference 94-4916.a Rudolf Landwehr 94-10-20
!reference 94-4919.a Mike Kamrad 94-10-21
!reference 94-4925.a Antoine Bertier 94-10-24
!from John Barnes 94-10-25
<>
!discussion
>> I support John's suggestion. IMHO, the change appears to small enough to
>> qualify as an editorial change.
> I strongly disagree with John's suggestion, at this stage of the process.
I detect the battle of Agincourt here.
>> The change will bring it in line with the
>> syntax for task, making one less exception in syntax for programmers to
>> worry about.
> This is absurd.
Don't use emotive words. Look at the meaning of absurd.
> I have yet to hear any real user complain about this. In fact
> this is the first time I see this mentionned at all. I am sorry if John cannot
> live with it (he certainly did for some years though ;-), but this is not
> enough to make a change in the language, especially at this late stage.
John complained about this many yeasr ago but no one seemed to listen.
In fact they all got the wrong end of the stick. And show me any real user wwho has used the feature yet anyway. Its more of pedagogic impotance. We are gerneally proud of oursyntax but this is just anb unfortunate consequenc of a nnew use of package.
I see no reason why we shouyld not put some small syntactic thing right now.
It would be foolish not to put such a trivial harmless thing corerct when one can.
Better than doing a hasty misreinterpretation of somehting semantically
serious.
John
From bobduff@dsd.camb.inmet.com Tue Oct 25 09:33:56 1994
Return-Path:
Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1)
id AA10304; Tue, 25 Oct 94 09:33:56 EDT
Received: from dsd.camb.inmet.com by inmet.camb.inmet.com (4.1/SMI-4.1)
id AA14858; Tue, 25 Oct 94 09:33:55 EDT
Received: by dsd.camb.inmet.com (4.1/SMI-4.1)
id AA10297; Tue, 25 Oct 94 09:33:49 EDT
Date: Tue, 25 Oct 94 09:33:49 EDT
From: bobduff@dsd.camb.inmet.com (Bob Duff)
Message-Id: <9410251333.AA10297@dsd.camb.inmet.com>
To: dewar@gnat.cs.nyu.edu
Cc: ada9x-mrt@inmet.com
In-Reply-To: <9410250438.AA10930@gnat.cs.nyu.edu> (dewar@gnat.cs.nyu.edu)
Subject: package syntax from acceptable to zero-trouble
Submitted at the request of Robert Dewar.
!topic package syntax from acceptable to zero-trouble
!reference RM9X-7.1;5.0
!reference 94-4911.a John Barnes 94-10-19
!reference 94-4916.a Rudolf Landwehr 94-10-20>>
!from the GNAT group at NYU
<>
!discussion
The package syntax, slightly uncomfortable as it might be is:
acceptable, bearable, compatible, do-able, established, familiar, goodenough,
handlable, ignorable, judicious, keen, liveable. malleable, non-critical,
ok, perspicious quasi-obvious, reasonable, same-as-Ada83, tactful,
unimportant, vivid, wrong-but-not-wrong-enough, x-emplary, yours!,
zero-trouble
From bobduff@dsd.camb.inmet.com Tue Oct 25 10:35:05 1994
Return-Path:
Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1)
id AA15724; Tue, 25 Oct 94 10:35:05 EDT
Received: from dsd.camb.inmet.com by inmet.camb.inmet.com (4.1/SMI-4.1)
id AA18423; Tue, 25 Oct 94 10:35:04 EDT
Received: by dsd.camb.inmet.com (4.1/SMI-4.1)
id AA15691; Tue, 25 Oct 94 10:35:03 EDT
Date: Tue, 25 Oct 94 10:35:03 EDT
From: bobduff@dsd.camb.inmet.com (Bob Duff)
Message-Id: <9410251435.AA15691@dsd.camb.inmet.com>
To: ada9x-mrt@inmet.com
Subject: Rounding for Put of floating point numbers
!topic Rounding for Put of floating point numbers
!reference RM9X-A.10.9(24);5.0
!from Bob Duff
<>
!discussion
3.5(33);5.0 requires 'Wide_Image to round away from zero, whereas
A.10.9(24) allows nondeterministic rounding for Put. (For floats, that
is.) Put should be changed to match 'Wide_Image.
- Bob
From stt@dsd.camb.inmet.com Tue Oct 25 14:02:11 1994
Return-Path:
Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1)
id AA25336; Tue, 25 Oct 94 14:02:11 EDT
Received: from dsd.camb.inmet.com by inmet.camb.inmet.com (4.1/SMI-4.1)
id AA27882; Tue, 25 Oct 94 14:02:09 EDT
Received: from spock.camb.inmet.com.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1)
id AA25329; Tue, 25 Oct 94 14:02:05 EDT
Date: Tue, 25 Oct 94 14:02:05 EDT
From: stt@dsd.camb.inmet.com (Tucker Taft)
Message-Id: <9410251802.AA25329@dsd.camb.inmet.com>
To: ada9x-mrt@inmet.com
Subject: Children of Generics are Broken
!topic Children of Generics are Broken
!reference RM9X-10.1.1(18-21);5.0
!reference RM9X-10.1.6(6);5.0
!reference 93-2951.a Norman Cohen 93-08-04
!from Tucker Taft 94-10-25
<>
!discussion
Over the past few months, as a result of a number of
questions and comments we have received relating to
children of generics, I have gradually developed the
opinion that the current formulation for children
of generics is quite badly broken.
This came to a head the last 2 days when we received
4 messages directly or indirectly related to children
of generics, basically showing how they don't do what
you want, you can't use them in natural ways, they don't
work well as formal packages, etc...
Luckily, one of these messages came along with an inkling
of a solution. The person said they had tried children
of generics, but they didn't work, but a nested
generic turned out to solve the problem. This morning a bell
finally wrang in my head, and I realized there is a very
natural solution to all of the problems. After a little
research, it turns out this solution is very close to something
suggested by Norm about a year ago.
CURRENT PROBLEMS
First, to summarize the problems with the current formulation:
1) To instantiate a child of a generic, both the instance of the
parent and the instance of the child must be library units;
and the instance of the child must be a child of the instance
of the parent.
2) When a child of a generic is used for a formal package parameter,
there is no way to know what instance of its parent is
associated with the actual instance of the child passed
in as the actual parameter.
3) The current formulation requires an ugly wart (10.1.6(6)) on
the rules for selected components, since normally you can't
make use of declarations nested inside a generic package
from outside the package.
The first problem is by far the most serious. It is enough
to make almost anyone shy away from using children of generics.
For example, we had originally considered using a child of
a generic for the image/value features of the discrete random
number package. However, to instantiate such an image/value
generic, both the original instance of the discrete random number
package, and the instance of the image/value generic, would
need to be library units. This is definitely not the
normal way of doing things, since you need to instantiate
the discrete random number generic with a subtype that
has exactly the range of interest. So one would have to
declare the subtype in a package, and then end the package,
and then create a child of that package which was the
instance of the random number package, and then a child
of that which would be the image/value package.
Given all of this, we concluded we could not use children
of generics for this.
Similar situations came up with the folks working on
the Ada/CORBA binding, and with a person who is working
on building a version of the Booch components in Ada 9X.
In every case, it became clear that children of generics
had to be avoided, primarily because of problem (1) above.
John Barnes has been working on updating his book for Ada 9X.
He bumped into problem (2), and had real trouble figuring
out how to make any use of a formal package whose template
was a child of a generic.
PROPOSED SOLUTION
The solution is quite straightforward. Rather than
directly instantiating a child of a generic, the effect
of "with"ing a child of a generic would be to make
visible a nested generic of the same name in every instance
of the parent generic.
We eliminate the requirement that an instance of a child
of a generic be a child of an instance of the parent.
You can instantiate the parent generic anywhere its visible.
Anywhere you "with" the child of the generic,
you can instantiate a corresponding nested generic
of any instance of the parent.
For example:
-- first we declare a generic and a child of the generic
generic
type T is (<>)
package Discrete_Random_Numbers is
type Generator is private;
function Next(Gen : Generator) return T;
...
end Discrete_Random_Numbers;
generic
package Discrete_Random_Numbers.Image_Value is
function Image(Gen : Generator) return String;
function Value(Str : String) return Generator;
end Discrete_Random_Numbers.Image_Value;
...
-- Now we instantiate the parent generic in a package
with Discrete_Random_Numbers;
package High_Roller is
type One_Die is range 1..6;
package Random_Die is new Discrete_Random_Numbers(One_Die);
...
end High_Roller;
-- Now we test the package, and make use
-- of the child of the generic.
with High_Roller; use High_Roller;
with Discrete_Random_Numbers.Image_Value;
procedure Test is
Gen : Random_Die.Generator;
package Random_IV is new Random_Die.Image_Value;
-- Random_Die.Image_Value is visible because corresponding
-- child of generic was mentioned in with clause.
D : One_Die;
begin
for I in 1..100 loop
D := Random_Die.Next(Gen);
Put_Line("You rolled a" & One_Die.Image'(D));
end loop;
Put_Line("State of generator = " & Random_IV.Image(Gen));
end Test;
-----------------------------
Formal packages also work quite naturally with this
formulation for children of generics. For example:
with Discrete_Random_Numbers.Image_Value;
generic
with package Ran is new Discrete_Random_Numbers(<>);
with package IV is new Ran.Image_Value;
...
package Discrete_Binomial_Distribution is
...
end Discrete_Binomial_Distribution;
---------------------------
COMPARISONS
Norm's proposal (93-2951.a) was quite similar, except
that that proposal required the parent generic to be instantiated
as a library unit if you wanted to make use of its
children -- if there were a child of the
generic, then there would be corresponding children
of such an instance, which could be "with"ed and then
instantiated.
In this proposal, there are no "implicit" library units
created. You only "with" explicitly defined library units,
including children of generics.
What this proposal does is make the consequence
of a "with" clause for a child library unit
more uniform, namely that if a compilation unit
mentions a child library unit in a with clause, then
from the point of view of that compilation unit, that
child is nested within the parent, and always has been.
If you don't mention a given child unit, then that child
effectively doesn't exist, and never has.
There are some aspects of this proposal that might be
felt somewhat less intuitive than the one in version 5.0,
but if you understand the general effect of a "with" clause,
then we believe this proposal is more consistent overall,
which should in the long run make it easier to understand.
Furthermore, because of problems (1) and (2) above,
the one in version 5.0 is badly broken and
essentially useless, and that's a sad thing to say for a
feature that is a nontrivial extension to the language.
PROPOSED WORDING
Here is some proposed new wording for 10.1.1(18-21):
A child of a parent generic library package shall be
instantiated or renamed only within the declarative region
of the parent generic.
For each child of a parent generic library package,
there is a declaration of a corresponding generic unit (or rename)
nested immediately within each instance of the parent generic.
Such a nested declaration is only visible within the
scope of a "with" clause that mentions
the corresponding child of the parent generic.
Paragraph 8.3(20) would be augmented to cover nested declarations
that correspond to a child of a generic package.
Paragraph 10.1.6(6) would be replaced with a much
simpler statement allowing one to "with" a child of a generic.
Paragraph 12.2(2) would be augmented to say
that the elaboration of the body of a child of a
generic allows a corresponding nested declaration
in an instance of the parent to be instantiated
without failing the Elaboration_Check.
-Tuck
From dritz@mcs.anl.gov Tue Oct 25 15:55:40 1994
Return-Path:
Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1)
id AA09801; Tue, 25 Oct 94 15:55:40 EDT
Received: from antares.mcs.anl.gov (antares9.mcs.anl.gov) by inmet.camb.inmet.com (4.1/SMI-4.1)
id AA02911; Tue, 25 Oct 94 15:55:35 EDT
Received: from mcs.anl.gov (papasun.mcs.anl.gov [140.221.6.132]) by antares.mcs.anl.gov (8.6.4/8.6.4) with ESMTP id OAA22993 for ; Tue, 25 Oct 1994 14:55:31 -0500
Message-Id: <199410251955.OAA22993@antares.mcs.anl.gov>
To: ada9x-mrt@inmet.com
Subject: Corrected definitions of the model-oriented attributes
X-Mailer: MH 6.8
Date: Tue, 25 Oct 1994 14:55:30 -0500
From: Ken Dritz
!topic Corrected definitions of the model-oriented attributes
!reference 94-4878.a Ken Dritz 94-10-13
!reference 94-4889.h Ken Dritz 94-10-9
!reference RM9X-G.2.2;5.0
!from Ken Dritz
<>
!discussion
In 94-4878.a, I presented revised definitions of the model-oriented floating
point attributes that answered comment 94-4454.a of David Guaspari.
Unfortunately, there is a mistake in those revised definitions, which is
corrected here. The correction is trivial; the explanation of the mistake is
not. However, this comment is bulky primarily because I chose to repeat here
the definitions of the model-oriented attributes with the trivial changes
incorporated.
The link between the operational precision provided by the predefined
arithmetic operations and the requested decimal precision of a type was
established (in 94-4878.a) by going indirectly through the base decimal
precision. In RM9X;5.0, base decimal precision is defined (in 3.5.7(9))
to be the actual representational precision of a type, which may (because of
anomalies in the arithmetic) be more than the operational precision. Given the
dependence (in 94-4878.a) of S'Model_Mantissa on the base decimal precision of
the type of S, once a hardware representation is tentatively chosen, the
accuracy of its operations cannot be satisfied if the arithmetic has anomalies,
and a "wider" representation must be chosen; but then the base decimal
precision increases, the accuracy requirements become more stringent, and again
they cannot be satisfied (if the arithmetic has anomalies).
The correction is to make S'Model_Mantissa depend directly on the requested
decimal precision of the type of S, not on the base decimal precision. This is
really quite obvious, and of course is the proper analog of what was in Ada 83.
The corrected definitions of the model-oriented attributes will read as
follows. Subclause G.2.2 is presented in its entirety, even though only one
word has changed (in three places), as compared to the superceded version in
94-4878.a.
G.2.2 Model-Oriented Attributes of Floating Point Types
In implementations that support this annex, the model-oriented attributes of
floating point types shall yield the values defined here, in both the strict
and the relaxed modes. These definitions add conditions to those in A.5.3.
Static Semantics
For any subtype S of a floating point type T:
S'Model_Mantissa Yields the number of digits in the mantissa of the
canonical form of the model numbers of T (see A.5.3). The
value of this attribute shall be greater than or equal to
ceiling(d * log(10) / log(T'Machine_Radix)) + 1, where d
is the requested decimal precision of T. In addition, it
shall be less than or equal to the value of
T'Machine_Mantissa. This attribute yields a value of the
type universal_integer.
Ramification: S'Model_Epsilon, which is defined in terms of
S'Model_Mantissa (see A.5.3), yields the absolute value of the difference
between one and the next model number of the type T above one. It is
equal to or larger than the absolute value of the difference between one
and the next machine number of the type T above one.
S'Model_Emin Yields the minimum exponent of the canonical form of the
model numbers of T (see A.5.3). The value of this
attribute shall be greater than or equal to the value of
T'Machine_Emin. This attribute yields a value of the type
universal_integer.
Ramification: S'Model_Small, which is defined in terms of S'Model_Emin
(see A.5.3), yields the smallest positive (nonzero) model number of the
type T.
S'Safe_First Yields the lower bound of the safe range of T. The value
of this attribute shall be a model number of T and greater
than or equal to the lower bound of the base range of T.
In addition, if T is declared by a
floating_point_definition or is derived from such a type,
and the floating_point_definition includes a
real_range_specification specifying a lower bound of lb,
then the value of this attribute shall be less than or
equal to lb; otherwise, it shall be less than or equal to
-10.0 ** (4*d), where d is the requested decimal precision
of T. This attribute yields a value of the type
universal_real.
S'Safe_Last Yields the upper bound of the safe range of T. The value
of this attribute shall be a model number of T and less
than or equal to the upper bound of the base range of T.
In addition, if T is declared by a
floating_point_definition or is derived from such a type,
and the floating_point_definition includes a
real_range_specification specifying an upper bound of ub,
then the value of this attribute shall be greater than or
equal to ub; otherwise, it shall be greater than or equal
to 10.0 ** (4*d), where d is the requested decimal
precision of T. This attribute yields a value of the type
universal_real.
S'Model Denotes a function (of a parameter X) whose specification
is given in A.5.3. If X is a model number of T, the
function yields X; otherwise, it yields the value obtained
by rounding or truncating X to either one of the adjacent
model numbers of T. Constraint_Error is raised if the
resulting model number is outside the safe range of S. A
zero result has the sign of X when S'Signed_Zeros is True.
Subject to the constraints given above, the values of S'Model_Mantissa and
S'Safe_Last are to be maximized, and the values of S'Model_Emin and
S'Safe_First minimized, by the implementation as follows:
o First, S'Model_Mantissa is set to the largest value for which values
of S'Model_Emin, S'Safe_First, and S'Safe_Last can be chosen so that
the implementation satisfies the strict-mode requirements of G.2.1 in
terms of the model numbers and safe range induced by these attributes.
o Next, S'Model_Emin is set to the smallest value for which values of
S'Safe_First and S'Safe_Last can be chosen so that the implementation
satisfies the strict-mode requirements of G.2.1 in terms of the model
numbers and safe range induced by these attributes and the previously
determined value of S'Model_Mantissa.
o Finally, S'Safe_First and S'Safe_last are set (in either order) to the
smallest and largest values, respectively, for which the
implementation satisfies the strict-mode requirements of G.2.1 in
terms of the model numbers and safe range induced by these attributes
and the previously determined values of S'Model_Mantissa and
S'Model_Emin.
Note that it is important, in the definition of S'Model_Mantissa, that d be the
requested decimal precision of T (not S). This is what prevents weakening of
the accuracy requirements for a "reduced accuracy subtype" (see
RM9X-I.3(8);5.0). It was not intended that a reduced accuracy subtype have
weaker accuracy requirements than its type, only that it have a smaller 'Digits
and therefore a smaller Default_Aft in Text_IO.Float_IO.
N.B.: The same change from base decimal precision to requested decimal
precision should be made in the core definition of S'Model_Mantissa given in
94-4889.h.
Ken
From dritz@mcs.anl.gov Tue Oct 25 16:04:38 1994
Return-Path:
Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1)
id AA11708; Tue, 25 Oct 94 16:04:38 EDT
Received: from antares.mcs.anl.gov (antares9.mcs.anl.gov) by inmet.camb.inmet.com (4.1/SMI-4.1)
id AA03281; Tue, 25 Oct 94 16:04:30 EDT
Received: from mcs.anl.gov (papasun.mcs.anl.gov [140.221.6.132]) by antares.mcs.anl.gov (8.6.4/8.6.4) with ESMTP id PAA23183 for ; Tue, 25 Oct 1994 15:04:27 -0500
Message-Id: <199410252004.PAA23183@antares.mcs.anl.gov>
To: ada9x-mrt@inmet.com
Subject: Meaning of "base decimal precision" and 'Base'Digits
X-Mailer: MH 6.8
Date: Tue, 25 Oct 1994 15:04:26 -0500
From: Ken Dritz
!topic Meaning of "base decimal precision" and 'Base'Digits
!reference RM9X-3.5.7(9);5.0
!reference 94-4913.f Kiyoshi Ishihata 94-10-19
!from Ken Dritz
<>
!discussion
This comment proposes a relatively minor change. It is long only because it
extensively discusses the rationale for the change.
Although this comment relates to 94-4913.f, it was not motivated by it; it was
already in the formative stage when 94-4913.f was posted.
RM9X-3.5.7(9);5.0 defines the "base decimal precision" of a floating point type
as "the number of decimal digits of precision representable in objects of the
type." I'll refer to that as "representational precision" in this comment.
For a floating point subtype S, RM9X-3.5.8(3);5.0 defines S'Base'Digits to
yield the base decimal precision of the type of S.
These definitions represent an incompatible change from Ada 83. There,
on the assumption that the 'Digits attribute of each predefined floating point
type is as large as possible given the need to satisfy the implied accuracy
requirements, S'Base'Digits yields the number of decimal digits of precision
achieved by the predefined operations of the type of S. I'll refer to that as
"operational precision" in this comment. The term "operational precision" is
applicable to Ada 9X as well, of course; that's what subclause G.2.1 is all
about. (In contrast, there is no analog of "representational precision" in Ada
83.) The model of floating point arithmetic caters to the fact that the
operational precision of a type may be less than its representational
precision, as actually occurs on some hardware; if there are no arithmetic
anomalies, the two are equal.
This incompatibility is potentially serious, since it means that the value of
S'Base'Digits can change between Ada 83 and Ada 9X (for a type whose arithmetic
has anomalies allowed by the model), even though no other significant aspect of
the implementation of the type changes.
S'Base'Digits is a (potentially) commonly used attribute in portable numeric
codes that are designed to adapt their behavior to the underlying hardware.
For example, it is used in Peter Tang's widely distributed implementation of
(the Ada 83 version of) Generic_Elementary_Functions to break certain
computations into several cases, each tailored to the capabilities of the
machine. A typical example is in the polynomial or rational approximation step
of the implementation of an elementary function, where, to attain the required
accuarcy, the degree of some approximating polynomial has to increase with
increasing values of Float_Type'Base'Digits. (Float_Type is the generic formal
parameter of Generic_Elementary_Functions. As Float_Type'Base'Digits
increases, the accuracy requirements become more stringent.) The effect of the
incompatible change in this case is to cause the implementation to work harder
than it needs to work to achieve the required accuracy.
In other cases, however, just the opposite could happen. Some computations are
designed to work harder to achieve the required accuracy when the hardware has
*less* capacity. A common example of this is the usual simulation of higher
precision by using multiple storage elements. If this technique is applied
conditionally when the operational precision of a type is "insufficient" for
the computation at hand, then the incompatible change will result in a failure
to achieve the required accuracy.
It may be argued that one should be using only S'Model_Mantissa to gauge the
implementation's operational precision. Doing so in a portable program is not
as convenient as using S'Base'Digits, since one must also take account of
differences in the value of S'Machine_Radix (S'Model_Mantissa gives the number
of radix-digits in the model numbers). Be that as it may, one has always been
able to use S'Base'Digits for this purpose, and portable codes employing that
technique exist; the existing technique should not be tampered with. One could
equally argue that only S'Machine_Mantissa should be used to gauge the
implementation's representational precision. While that suffers the same
inconvenience of being measured in radix-digits, nothing about it has changed
since Ada 83, and existing experience continues to be relevant.
The notion of operational precision can only be defined in Annex G, where it
needs all the machinery of the floating point model; it cannot be fully defined
in the core. An implementation of Ada 9X that does not support Annex G is not
required to deliver any particular operational precision. This leaves open the
possibility that S'Base'Digits can be defined to yield operational precision in
Annex G, while retaining only an implementation-defined meaning in the core (so
that Annex G merely refines its core meaning, rather than conflicting with it).
One consequence of not pinning down the value of S'Base'Digits in the core is
that its value may change when a core-only implementation becomes a
core-plus-Annex-G implementation. That its value in the core-only
implementation might differ from its value in Ada 83 is excusable on the
grounds that the implementation does not fully support numerics. Such a
difference would not be excusable in a core-plus-Annex-G implementation, which
does fully support numerics. The effect of this comment is to ensure that
implementations that fully support numerics give S'Base'Digits the same value
as in Ada 83.
The incompatibility at the heart of this comment, i.e. the change in the
meaning of S'Base'Digits from operational precision to representational
precision, is of relatively recent origin. It was introduced when RM9X-3.5.7
was changed to give effect to Villars Resolution 27 (and the corresponding
comment 94-4034.za). In RM9X;4.0, base decimal precision was defined
(informally in 3.5.7) to mean operational precision.
There are perhaps two ways in which the incompatibility can be eliminated,
differing in the degree to which they preserve the spirit of Resolution 27.
One is to revert to the version 4.0 definition of base decimal precision as
operational precision. I do not favor this approach, because it is
problematical (limited to an informal definition of operational precision, and
therefore not very effective); it also misses an opportunity to correct the
problem perceived in 94-4913.f. It has the effect of totally reversing
Resolution 27.
Instead, I propose to retain the definition of base decimal precision as
representational precision, thereby preserving the spirit of Resolution 27, but
to decouple S'Base'Digits from it, allowing the latter to mean operational
precision. The way in which I accomplish the latter coincidentally satisfies
the main criticism of 94-4913.f, as discussed below.
The approach has the following elements:
o Continue to define base decimal precision (in 3.5.7(9)) as
representational precision. Continue to use base decimal precision as
the selection criterion in 3.5.7(10). That is, do not change paragraph 9
or the first sentence of paragraph 10.
o Omit reference to S'Base'Digits from 3.5.7(10); i.e., delete the second
sentence of paragraph 10.
o Define the meaning of REQUESTED decimal precision for the unconstrained
subtype S'Base of the type of S. Each subtype S of a floating point type
T has a potentially different requested decimal precision. For a
user-declared type and its first subtype, the requested decimal precision
comes from the declaration (3.5.7(4)). For a reduced accuracy subtype,
it comes from the digits_constraint of the subtype_indication (I.3(8)).
For any other subtype created by a subtype_declaration, it is the same as
that of the subtype denoted by the subtype_mark (3.2.2(9)). For a
predefined type and its first subtype, it comes from the declaration in
Standard. For a derived type, it is the same as that of its parent type;
for the first subtype thereof, it is the same as that of the parent
subtype (3.4(6)). However, the base subtype of T, which is denoted by
S'Base, is not a subtype "created" by a type_declaration or
subtype_declaration and therefore does not seem to have a defined
requested decimal precision (as was pointed out by 94-4913.f).
94-4913.f considered the meaning of S'Base'Digits to be ambiguous,
because it is both explicitly defined in 3.5.8(3) to yield the base
decimal precision of the type of S and might also be interpreted to mean
the 'Digits attribute of the subtype S'Base, which would yield the
requested decimal precision of the base subtype of the type of S (except
that the latter is presently undefined).
I suggest removing the explicit definition of S'Base'Digits from 3.5.8(3)
and letting its meaning be inferred from the meaning of S'Base and
'Digits. This requires defining the meaning of the requested decimal
precision for S'Base. It should be defined (in the core) as the largest
value of d for which
ceiling(d * log(10) / log(T'Machine_Radix)) + 1 <= T'Model_Mantissa,
where T is the type of S. In the context of Annex G, this definition
yields the desired (decimal) operational precision, because of the
definition of S'Model_Mantissa that applies there. In the context of the
core, this definition yields an implementation-defined value, because
S'Model_Mantissa is only implementation defined in the core (see
94-4889.h and 94.4934.a). Note that this definition was anticipated in
the Rationale (see the algorithm for determining the value of the 'Digits
attribute of a predefined floating point type, presented near the end of
part III section 6.4.1). It is also reminiscent of one aspect of the Ada
83 floating point equivalence rule (RM83-3.5.7(10-12)), which is not
needed for Ada 9X.
The most appropriate place for the definition given above is not crystal
clear, but perhaps a logical place for it would be as an addition to
3.5.8(2), e.g.,
The requested decimal precision of the base subtype of a floating
point type T is defined to be the largest value of d for which
ceiling(d * log(10) / log(T'Machine_Radix)) + 1 <= T'Model_Mantissa.
After these changes, it must be verified that the term "base decimal
precision" is used nowhere except in 3.5.7(10), since it still means
representational precision. It has already been eliminated from the
definitions of the model-oriented attributes.
Note that the changes outlined above allow (but do not require) a core-only
implementation to select a hardware representation for a user-declared floating
point type that would not be allowed by Annex G. Everything that Annex G
requires, however, is allowed by the core.
As an example, consider
type T is digits 5;
subtype S is T digits 4; -- a reduced accuracy subtype (see I.3(8))
and suppose that we have a garden-variety implementation that supports Annex G
and employs the usual single-precision binary hardware representation for T,
with an operational accuracy of 6 decimal digits. Such an implementation will
likely have T'Machine_Mantissa = 24. How do we know that S'Base'Digits is 6 in
this case?
Applying the definition of 'Digits to S'Base, we find that we need the
requested decimal precision of S'Base, and furthermore that that is defined as
the maximum value of d such that ceiling(d * log(10) / log(2)) + 1 <=
T'Model_Mantissa. We therefore need to know the value of T'Model_Mantissa.
Applying the definition of 'Model_Mantissa to T, we learn that T'Model_Mantissa
is some value greater than or equal to ceiling(d * log(10) / log(2)) + 1, where
d is the requested decimal precision of T (which is 5); thus, T'Model_Mantissa
>= 18. We also learn that T'Model_Mantissa is less than or equal to
T'Machine_Mantissa, which is 24. Finally, we learn that, subject to these
constraints, it is the (implementation-dependent) maximum value for which
values of certain other model-oriented attributes can be chosen so that the
accuracy requirements implied by the resulting set of model numbers and safe
range are satisfied. If there are no arithmetic anomalies requiring precision
penalties, that maximum value will be 24, the value of T'Machine_Mantissa. If
there are minor anomalies (like lack of a guard digit), requiring modest
precision penalties, it may be only 23 or 22. As long as it is a value between
21 and 24, the formula for the requested decimal precision of S'Base will yield
6.
(Suppose we now add the declaration
subtype Q is S'Base;
and ask what the value of Q'Digits is. It should be clear that the value will
be 6. It is not at all clear that RM9X;5.0 yields this value, or indeed any
value.)
Ken
From @sheila:swb@igor Tue Oct 25 17:36:46 1994
Return-Path: <@sheila:swb@igor>
Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1)
id AA17737; Tue, 25 Oct 94 17:36:46 EDT
Received: from Rational.COM by inmet.camb.inmet.com (4.1/SMI-4.1)
id AA08500; Tue, 25 Oct 94 17:36:40 EDT
Received: from igor.Rational.COM by Rational.COM (8.6.9/rational-1.0.2) id VAA07361; Tue, 25 Oct 1994 21:36:04 GMT
Received: from sheila by igor.Rational.COM (4.1/smh-1.0)
id AA21305; Tue, 25 Oct 94 14:36:22 PDT
Message-Id: <9410252136.AA21305@igor.Rational.COM>
Date: Tue, 25 Oct 94 14:29:30 PDT
From: swb@Rational.COM
To: ada9x-mrt@inmet.com
Cc: swb@igor
Subject: ada9x query
Hop-Count: 1
!topic abstract types and subprograms
!reference AARM-3.9.3(3);5.0
!from Stephen Baird
<>
!discussion
3.9.3(3) states that if an abstract subprogram is a primitive subprogram
of a tagged type, then the tagged type shall be abstract.
How is this rule applied in the case where the tagged type has a
partial view which is abstract, but the corresponding full view is not?
For example:
package P is
type T is abstract tagged private;
function Foo (X : T) return Boolean is abstract; -- legal?
private
type T is tagged null record;
X : T;
Y : Boolean := Foo (T'Class (X));
end P;
From dritz@mcs.anl.gov Tue Oct 25 17:56:27 1994
Return-Path:
Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1)
id AA18346; Tue, 25 Oct 94 17:56:27 EDT
Received: from antares.mcs.anl.gov (antares9.mcs.anl.gov) by inmet.camb.inmet.com (4.1/SMI-4.1)
id AA09310; Tue, 25 Oct 94 17:56:22 EDT
Received: from mcs.anl.gov (papasun.mcs.anl.gov [140.221.6.132]) by antares.mcs.anl.gov (8.6.4/8.6.4) with ESMTP id QAA25186 for ; Tue, 25 Oct 1994 16:56:19 -0500
Message-Id: <199410252156.QAA25186@antares.mcs.anl.gov>
To: ada9x-mrt@inmet.com
Subject: Rounding of fixed-to-integer conversion
X-Mailer: MH 6.8
Date: Tue, 25 Oct 1994 16:56:17 -0500
From: Ken Dritz
!topic Rounding of fixed-to-integer conversion
!reference 94-4920.a Bob Duff 94-10-21
!reference RM9X-G.2.3(18);5.0
!from Ken Dritz
<>
!discussion
Bob wrote:
> This paragraph allows a fixed point value exactly halfway between two
> integers to be rounded nondeterministically to either surrounding
> integer. This seems to conflict with 4.6(33), which requires rounding
> away from zero in this case. G.2.3(18) should be changed.
I was going to agree with Bob until I checked carefully what G.2.3 had to say
about fixed-to-integer conversion.
I don't think it's that straightforward. Bob is assuming that the result of
the conversion is in what G.2.3 defines as the "perfect result set" (meaning
essentially not more than one rounding error). But it need not be;
counterexamples can be constructed using the information in paragraphs 24 and
20-21. If the result of fixed-to-integer conversion is only in the "close
result set" (meaning essentially more than one rounding error), then the result
need not even be one of the immediately adjacent integer values. If this
material is correct, then it is 4.6(33) that should be changed, making it read
more like 4.6(32) reads (i.e., just referencing G.2).
In particular, the result of fixed-to-integer conversion will be in the close
result set when the small of the fixed point source operand is not an integer
or the reciprocal of an integer. In this case, the conversion cannot be
performed simply by multiplying or dividing the internal (scaled integer)
representation of the source value by a single integer (and then rounding).
Incidentally, in G.2.3(7), the words "and for the conversion of a value v to a
fixed point type" should be changed to "and for the conversion of a value v to
a fixed point type (or from a fixed point type to an integer type)".
Ken
From ibc@ocsystems.com Tue Oct 25 18:42:00 1994
Return-Path:
Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1)
id AA20490; Tue, 25 Oct 94 18:42:00 EDT
Received: from ocsystems.com by inmet.camb.inmet.com (4.1/SMI-4.1)
id AA11755; Tue, 25 Oct 94 18:41:53 EDT
Received: by ocsystems.com (AIX 3.2/UCB 5.64/4.03)
id AA14367; Tue, 25 Oct 1994 18:22:05 -0400
Date: Tue, 25 Oct 1994 18:22:05 -0400
From: ibc@ocsystems.com (Ivan B. Cvar)
Message-Id: <9410252222.AA14367@ocsystems.com>
To: -s@ocsystems.com, 5.0@ocsystems.com, RM9X@ocsystems.com,
ada9x-mrt@inmet.com, errors@ocsystems.com, version@ocsystems.com
!topic Incorrect paragraph numbers when referring to S'Base
<>
!discussion
In RM9X, version 5.0, every reference to S'Base that I've found was
consistent, but wrong.
Refs to 3.5(14) should refer to 3.5(15)
Refs to J(16) should refer to J(18)
Please fix: 2 places on index pg 515,
Annex J(18),
perhaps other places too?
!topic Inconsistent or missing S' references in index:
<>
!discussion
In RM9X, version 5.0, the index on page 546 that references S' attributes
seems inconsistent because it lists only some of the S'attributes that
are listed in Annex J while others are ommited from the index.
Why are some S' attributes listed in the index while others are omitted?
For example, S'Aft, S'Base, S'Bit_Order, S'Class, S'Definite, and perhaps
other attributes beginning with the prefix S were (accidently?) omitted
from page 546 of the index.
Similarly, why are other attributes that are listed in Annex J but that
do not begin with the letter S not listed in the index? For example,
neither T'Storage_Size, P'Access, X'Address, nor any other attribute
whose prefix isn't an S, are listed at the beginning of their repective
sections in the index.
This seems inconsistent.
From @sheila:swb@igor Tue Oct 25 21:05:46 1994
Return-Path: <@sheila:swb@igor>
Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1)
id AA26481; Tue, 25 Oct 94 21:05:46 EDT
Received: from Rational.COM by inmet.camb.inmet.com (4.1/SMI-4.1)
id AA17325; Tue, 25 Oct 94 21:05:38 EDT
Received: from igor.Rational.COM by Rational.COM (8.6.9/rational-1.0.2) id BAA08730; Wed, 26 Oct 1994 01:05:14 GMT
Received: from sheila by igor.Rational.COM (4.1/smh-1.0)
id AA23616; Tue, 25 Oct 94 18:05:31 PDT
Message-Id: <9410260105.AA23616@igor.Rational.COM>
Date: Tue, 25 Oct 94 17:58:43 PDT
From: swb@Rational.COM
To: ada9x-mrt@inmet.com
Cc: swb@igor
Subject: ada9x query
Hop-Count: 1
!topic record extensions
!reference AARM-3.9.1(9);5.0
!from Stephen Baird
<>
!discussion
3.9.1(9) states that each visible component of a record extension must
have a unique name. It is not clear what this means in the case where
a component is visible in one context but not in another. For example:
procedure Foo is
package P is
type T is tagged private;
private
type T is tagged
record
F : Integer;
end record;
end P;
package Q is
type D is new P.T with
record
F : Float; -- legal? (1st F component not visible here)
end record;
end Q;
package body P is
X : Q.D;
Y : Float renames X.F; -- legal?
begin
X := (F => 1, F => 1.0); -- legal?
end P;
begin
null;
end Foo;
If the extension is legal, then it seems intuitively clear that any uses
of the name F are ambiguous within the body of P. The precise RM justification
for this position is less clear.
From @sheila:swb@igor Tue Oct 25 23:33:33 1994
Return-Path: <@sheila:swb@igor>
Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1)
id AA22772; Tue, 25 Oct 94 23:33:33 EDT
Received: from Rational.COM by inmet.camb.inmet.com (4.1/SMI-4.1)
id AA23909; Tue, 25 Oct 94 23:33:30 EDT
Received: from igor.Rational.COM by Rational.COM (8.6.9/rational-1.0.2) id DAA10111; Wed, 26 Oct 1994 03:33:10 GMT
Received: from sheila by igor.Rational.COM (4.1/smh-1.0)
id AA24626; Tue, 25 Oct 94 20:33:27 PDT
Message-Id: <9410260333.AA24626@igor.Rational.COM>
Date: Tue, 25 Oct 94 20:26:38 PDT
From: swb@Rational.COM
To: ada9x-mrt@inmet.com
Cc: swb@igor
Subject: ada9x query
Hop-Count: 1
!topic derivation from tagged types
!reference AARM-7.3(6);5.0
!from Stephen Baird
<>
!discussion
7.3(6) states that "In the case where the partial view is untagged and
the full view is tagged, no derivatives of the partial view are allowed
within the immediate scope of the partial view".
This suggests that such a derivation is legal outside of the immediate
scope of the partial view. The derived type may then be referenced from
within a scope which can see the full (tagged) view of the parent type.
When viewed from within such a scope, is such a derived type a tagged type?
Although 7.3.1(4) clearly does not apply in this case, I am still uncertain.
Equivalently:
Does such a derived type need a distinct Tag value (and, in implementation
terms, its own type descriptor)?
Can calls to the primitive subprograms of such a derived type be
dispatching calls?
Can such a derived type be extended?
For example:
with Ada.Tags;
procedure Foo is
package P is
type T is private;
procedure PP (X : T);
private
type T is tagged null record;
end P;
package Q is
type D is new P.T;
procedure PP (X : D);
end Q;
package body Q is
procedure PP (X : D) is ... ;
end Q;
package body P is
procedure PP (X : T) is ... ;
Same_Tag : constant Boolean
:= Ada.Tags."=" (T'Tag, Q.D'Tag);
-- True, False, or illegal?
X : Q.D;
package R is
type Extended is new Q.D with null record; -- legal?
end R;
begin
Q.PP (X); -- do these two calls execute
Q.PP (Q.D'Class (X)); -- the same body? 3.9.2(19.b) says
-- "the same body is executed for
-- a given tag, whether the tag is
-- determined statically or dynamically".
-- Does the second call violate 3.9.2(9)?
end P;
begin
null;
end Foo;