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;