From bjkae@celsiustech.se Thu Oct 27 03:58:43 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA08809; Thu, 27 Oct 94 03:58:43 EDT Received: from world.celsiustech.se by inmet.camb.inmet.com (4.1/SMI-4.1) id AA06156; Thu, 27 Oct 94 03:58:37 EDT Received: (bjkae@localhost) by world.celsiustech.se (8.6.9/8.6.4) id IAA29890 for ada9x-mrt@inmet.com; Thu, 27 Oct 1994 08:58:26 +0100 Date: Thu, 27 Oct 1994 08:58:26 +0100 From: Bjorn Kallberg Message-Id: <199410270758.IAA29890@world.celsiustech.se> To: ada9x-mrt@inmet.com Subject: Unchecked conversion and C unions !topic Improve Unchecked_conversion and C union interface !reference RM9X-B.3(72);5.0 !reference RM9X-13.9;5.0 !from Bjorn Kallberg 94-10-27 <> !discussion Many other strongly typed has an operation (type cast) to avoid the strong typing, when needed. Ada lacks this facility, but has unchecked_conversion (UC). In Ada 9x, the unchecked_conversion is also to be used for interfacing with C (unions). As interfacing (to C) is one of the important improvements for Ada9x, the importance of unchecked_conversion is also increased. The drawbacks of UC should thus be made as small as possible. The difference between a pure type cast, an the Unchecked_conversion of Ada is 1. UC is not only an information to the compiler, but can generate code during runtime. This amount of code can be substantial (One Ada87 compiler generates more than 100 bytes). 2. It is allowed to limit the legality of UC. (e.g. not allow conversions between types of unequal length, or not static lengths) 3. UC is not a conversion, i.e. it can not be used for out parameters. All of this limits the portability and usability of UC. It is probably to late to get a change for point 3 above, i.e. make UC to a pure view conversion. However, implementation advice could improve points 1 and 2. Thus, I suggest that 13.9 are changed, with the implementation advices and notes with the following meanings. - Change 13.9(12) to not only make it permissible, but indicate that this is the preferred behaviour (to just return the same reference, to get another view of the operand) - UC should ideally be a compile_time_only operation, and at least not be a time consuming or stack consuming operation - UC should always be possible between constrained objects, even if S'size /= target'size. (this is probably the most common case for C unions) - An implementation should be forbidden to impose any restrictions on Unchecked_conversion. (E.g. conversion from a task type to an integer may return the first word of the task control block, or an adress, or anything else) (remove 13.9(13)). - Warnings for potentially dangerous use of UC is incouraged. - Use of UC is completely up to the user, i.e. anything could happen (e.g. the dope vector is interpreted as data, etc) Of course, another solution to the above problem may be to introduce discriminated records without storage of the discriminant, in the same way as Pascal does (pragma Unchecked_record?) Bj|rn K{llberg From Steve.Han@reading.ac.uk Thu Oct 27 07:10:28 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA17370; Thu, 27 Oct 94 07:10:28 EDT Received: from mail1.rdg.ac.uk (sussdirt.rdg.ac.uk) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA14885; Thu, 27 Oct 94 07:10:18 EDT Received: from csres.cs.reading.ac.uk (actually lovage.rdg.ac.uk) by sussdirt.rdg.ac.uk with SMTP - Local (PP); Thu, 27 Oct 1994 11:09:42 +0000 Received: from aquila.CSres (orion) by csres.cs.reading.ac.uk (4.1) id; Thu, 27 Oct 94 11:09:35 GMT Date: Thu, 27 Oct 94 11:09:35 GMT From: Steve.Han@reading.ac.uk ( Steve Han) Message-Id: <9410271109.AA28036@csres.cs.reading.ac.uk> To: ada9x-mrt@inmet.com To: ada9x-mrt@inmet.com !topic Problem instantiating a generic package formal "private" type <> parameter with an incompletely declared type to create a linked list based on a controlled access type !reference RM9X-3.10.1;5.0, RM9X-12.5.1;5.0, RM9X-7.6;5.0 !from Phil Slater 94-10-06 (J.Slater@reading.ac.uk) !keywords controlled instantiation incomplete !discussion I attempted to create an assignable, self-deallocating ADT based on a linked list, by making the linking access type controlled. The following generic package specification defines the access type: ----------------------------------------------------------------------------- with Ada.Finalization; generic type Anything is private; type Pointer is access Anything; package AutoPointer_Package is type AutoPointer is new Ada.Finalization.Controlled with record Ptr : Pointer; end record; procedure Initialize (Object : in out AutoPointer); procedure Adjust (Object : in out AutoPointer); procedure Finalize (Object : in out AutoPointer); end AutoPointer_Package; ----------------------------------------------------------------------------- The body of this package is not relevant so is not included. Following this, I had to create the linked list using an instance of AutoPointer in place of the normal access type: ----------------------------------------------------------------------------- with AutoPointer_Package; generic type List_Element is limited private; package AssList is type Assignable_List is private; -- ... subprograms etc here private type List_Node; type List_Node_Ptr is access List_Node; package AutoLink is new AutoPointer_Package (List_Node, List_Node_Ptr); type List_Node is record Value : List_Element; Next : AutoLink.AutoPointer; end record; type Assignable_List is new AutoLink.AutoPointer with null record; end AssList; ----------------------------------------------------------------------------- The instantiation of package AutoLink appears to be illegal at the position it is placed, because the declaration of type Link_Node is incomplete. However, it cannot appear anywhere else! For example, the GNAT compiler gave the following: F:\DJGPP\JPS>gcc -c asslist.ads asslist.ads:10:50: premature use of incomplete type asslist.ads:10:50: invalid use of type before its full declaration compilation abandoned Is it worth considering allowing the use of an incompletely declared type for generic instantiation to permit this functionality to be achieved, (or is there something obvious I have missed?!) THIS MESSAGE HAS BEEN SENT BEFORE, BUT OWING TO MAILER PROBLEMS AT READING ALL MY INCOMING MAIL WAS LOST, SO I AM NOT SURE IF YOU RECEIVED IT. IF YOU'VE ALREADY SENT A REPLY, PLEASE COULD YOU RE-SEND TO: J.SLATER@READING.AC.UK THANKS. From Steve.Han@reading.ac.uk Thu Oct 27 07:10:31 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA17396; Thu, 27 Oct 94 07:10:31 EDT Received: from by inmet.camb.inmet.com (4.1/SMI-4.1) id AB14885; Thu, 27 Oct 94 07:10:29 EDT Received: from csres.cs.reading.ac.uk (actually lovage.rdg.ac.uk) by sussdirt.rdg.ac.uk with SMTP - Local (PP); Thu, 27 Oct 1994 11:10:05 +0000 Received: from aquila.CSres (orion) by csres.cs.reading.ac.uk (4.1) id; Thu, 27 Oct 94 11:09:44 GMT Date: Thu, 27 Oct 94 11:09:44 GMT From: Steve.Han@reading.ac.uk ( Steve Han) Message-Id: <9410271109.AA28039@csres.cs.reading.ac.uk> To: ada9x-mrt@inmet.com To: ada9x-mrt@inmet.com !topic Controlled types are not portable! !reference RM9X-3.9.1(8);5.0, RM9X-7.6(4-7);5.0 !from Phil Slater 94-10-06 (J.Slater@reading.ac.uk) !keywords controlled portable component record_extension_part <> !discussion RM9X-3.9.1(8) states that a name that denotes a component (...) of the parent type is not allowed within the record_extension_part. The parent of controlled types is the type Controlled (RM9X-7.6) which is declared as abstract tagged private. The private part of Ada.Finalization is stated in RM9X-7.6(7) to be "not specified by the language". Thus the names of the components of the type Controlled will vary from implementation to implementation. It follows that programmers who wish to declare controlled types will have to avoid component name conflicts between their record_extension_part and the type Controlled in the implementation of Ada.Finalization which they are using. It is thus impossible to choose names for components of the record_extension_part which are portable. The same problem applies to any tagged private ancestor types anywhere in an inheritance hierarchy: the names of all components, whether private or not, must be taken into consideration in naming the components of derived types with a record_extension_part. This cuts across the information hiding principle, which should ensure that the author of the ancestor type can make alterations to the private parts of the type without affecting other parts of the system. The solution to this problem is for inherited components which are declared as private in the ancestor types to be completely invisible in the derived type, including the possibility of components in the derived type having the same name as inherited components which were declared as private. THIS MESSAGE HAS BEEN SENT BEFORE, BUT OWING TO MAILER PROBLEMS AT READING ALL MY INCOMING MAIL WAS LOST, SO I AM NOT SURE IF YOU RECEIVED IT. IF YOU'VE ALREADY SENT A REPLY, PLEASE COULD YOU RE-SEND TO: J.SLATER@READING.AC.UK THANKS. From eachus@spectre.mitre.org Thu Oct 27 09:20:52 1994 Return-Path: Received: from mbunix.mitre.org by dsd.camb.inmet.com (4.1/SMI-4.1) id AA20907; Thu, 27 Oct 94 09:20:52 EDT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.6.9/8.6.9) with ESMTP id JAA05079 for ; Thu, 27 Oct 1994 09:20:46 -0400 Received: from localhost (eachus@localhost) by spectre.mitre.org (8.6.4/8.6.4) id JAA10353; Thu, 27 Oct 1994 09:20:45 -0400 Date: Thu, 27 Oct 1994 09:20:45 -0400 From: "Robert I. Eachus" Message-Id: <199410271320.JAA10353@spectre.mitre.org> To: ada9xmrt@dsd.camb.inmet.com In-Reply-To: Bob Duff's message of Wed, 26 Oct 94 14:36:45 EDT <9410261836.AA15791@dsd.camb.inmet.com> Subject: Legality of Static Decimal Expressions !topic Legality of Static Decimal Expressions !reference RM9X-4.9(35);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>> !reference 94-4929.a Robert Dewar 94-10-25 !reference as: 94-4950.a Bob Duff 94-10-26 !from Robert I. Eachus 94-10-27 <> !discussion Bob Duff said: > 35 The expression is illegal if its evaluation fails a > language-defined check other than Overflow_Check. If the > expression is not part of a larger static expression, then its > value shall be within the base range of its expected type. If > the expression is of type universal_real and its expected type is > a decimal fixed point type, then its value shall be a multiple of > the small of the decimal type. These restrictions do not apply > if the expected type is a descendant of a formal scalar type (or > a corresponding actual type in an instance). "then its value shall be a multiple of the small of the decimal type." Is this a requirement on the implementation (as I expect) or on the programmer (as it seems to read). In other words is: Weekly_Salary: Dollars := 100_000.00/52; -- legal? Replacing "shall be" by "shall be converted to" or "shall be evaluated as" would make it easier to understand. Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From bobduff Thu Oct 27 09:38:08 1994 Return-Path: Received: by dsd.camb.inmet.com (4.1/SMI-4.1) id AA21877; Thu, 27 Oct 94 09:38:08 EDT Date: Thu, 27 Oct 94 09:38:08 EDT From: bobduff (Bob Duff) Message-Id: <9410271338.AA21877@dsd.camb.inmet.com> To: eachus@spectre.mitre.org Cc: ada9xmrt@dsd.camb.inmet.com In-Reply-To: <199410271320.JAA10353@spectre.mitre.org> (eachus@spectre.mitre.org) Subject: Re: Legality of Static Decimal Expressions !topic Legality of Static Decimal Expressions !reference RM9X-4.9(35);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>> !reference 94-4929.a Robert Dewar 94-10-25 !reference as: 94-4950.a Bob Duff 94-10-26 !reference 94-4957.a Robert I. Eachus 94-10-27 !from Bob Duff <> !discussion Robert Eachus said: > Bob Duff said: > > > 35 The expression is illegal if its evaluation fails a > > language-defined check other than Overflow_Check. If the > > expression is not part of a larger static expression, then its > > value shall be within the base range of its expected type. If > > the expression is of type universal_real and its expected type is > > a decimal fixed point type, then its value shall be a multiple of > > the small of the decimal type. These restrictions do not apply > > if the expected type is a descendant of a formal scalar type (or > > a corresponding actual type in an instance). > > "then its value shall be a multiple of the small of the decimal > type." > > Is this a requirement on the implementation (as I expect) or on > the programmer (as it seems to read). It is a requirement on the programmer, as it seems to be ;-). This rule has been there for a long time, and we are not proposing to change it. - Bob From bobduff Thu Oct 27 10:34:36 1994 Return-Path: Received: by dsd.camb.inmet.com (4.1/SMI-4.1) id AA23721; Thu, 27 Oct 94 10:34:36 EDT Date: Thu, 27 Oct 94 10:34:36 EDT From: bobduff (Bob Duff) Message-Id: <9410271434.AA23721@dsd.camb.inmet.com> To: eachus@spectre.mitre.org, ada9xmrt@dsd.camb.inmet.com In-Reply-To: <9410271338.AA21877@dsd.camb.inmet.com> (bobduff) Subject: Re: Legality of Static Decimal Expressions !topic Legality of Static Decimal Expressions !reference RM9X-4.9(35);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>> !reference 94-4929.a Robert Dewar 94-10-25 !reference as: 94-4950.a Bob Duff 94-10-26 !reference 94-4957.a Robert I. Eachus 94-10-27 !reference 94-4958.a Bob Duff 94-10-27 !from Bob Duff <> !discussion I should have answered this example specifically, as well as the general question: > Weekly_Salary: Dollars := 100_000.00/52; -- legal? The example is legal, since the expression 100_000.00/52 is not of type universal_real -- it's of type Dollars. Thus, the expression does not disobey the rule. (It's still a rule for the programmer, though, as I said in my previous message.) - Bob From stt Thu Oct 27 13:22:41 1994 Return-Path: Received: from spock.camb.inmet.com.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA07204; Thu, 27 Oct 94 13:22:41 EDT Date: Thu, 27 Oct 94 13:22:41 EDT From: stt (Tucker Taft) Message-Id: <9410271722.AA07204@dsd.camb.inmet.com> To: ada9xmrt@dsd.camb.inmet.com, bobduff, eachus@spectre.mitre.org Subject: Re: Legality of Static Decimal Expressions !topic Legality of Static Decimal Expressions !reference RM9X-4.9(35);5.0 !reference 94-4950.a Bob Duff 94-10-26 !reference 94-4957.a Robert I. Eachus 94-10-27 !reference 94-4958.a Bob Duff 94-10-27 !reference 94-4959.a Bob Duff 94-10-27 !from Tucker Taft 94-10-27 <> !discussion > I should have answered this example specifically, as well as the general > question: > > > Weekly_Salary: Dollars := 100_000.00/52; -- legal? > > The example is legal, since the expression 100_000.00/52 is not of type > universal_real -- it's of type Dollars. Thus, the expression does not > disobey the rule. (It's still a rule for the programmer, though, as I > said in my previous message.) The legality rule specifies universal_real. The result of fixed-point multiplication or division is never universal_real; it is either universal_fixed (for fixed-fixed) or the target type (for fixed-integer). I might add that the purpose of this rule is to help catch mistakes when using real literals for decimal types. For example: type Interest_Rate is delta 0.0001 range 0.0 .. 0.9999; Annual_Interest : Interest_Rate := 0.09375; would be flagged as illegal, since it is not a multiple of the delta. You can always force the issue, by using an explicit conversion: Annual_Interest : Interest_Rate := Interest_Rate(0.09375); The compiler won't complain about this one. The explicit conversion will truncate off the extra digit. The underlying presumption about decimal types is that they are used for calculations that require exact, portable semantics, perhaps due to financial accountability requirements. For example, truncation is required after multiplication division, or explicit conversion, unless there is an explicit use of the 'Round attribute function. For the case of a real literal, it seemed useful to detect when truncation would have happened, and flag it, since the user can easily write exactly what they want. If they write an extra decimal place, there is probably something out of wack, and they likely won't get the answer they expect, and wonder why. In the above example, the error might be that the programmer should have declared Interest_Rate to have a smaller delta, or that the interest rate was mis-entered. This legality check, by identifying an inconsistency in number of decimal places, should help to catch such errors. That after all is the primary purpose of legality checks, to identify inconsistencies that might indicate an underlying error. And as usual, explicit conversion is one way to specifically override a legality check, when you (supposedly ;-) "know" what you are doing. You can think of this legality check as complementing the range checks. If a programmer mistakenly thinks the Interest_Rate is a percentage rather than a ratio, the range check will catch the problem (presuming the interest rate is greater than 1%!). If on the other hand, if some type is representing a percentage with two decimal places, and a programmer thinks it is a ratio with four decimal places, then the "multiple-of-small" check can catch the problem. > - Bob -Tuck From @sheila:swb@igor Thu Oct 27 17:21:55 1994 Return-Path: <@sheila:swb@igor> Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA29976; Thu, 27 Oct 94 17:21:55 EDT Received: from Rational.COM by inmet.camb.inmet.com (4.1/SMI-4.1) id AA14868; Thu, 27 Oct 94 17:21:49 EDT Received: from igor.Rational.COM by Rational.COM (8.6.9/rational-1.0.2) id VAA24581; Thu, 27 Oct 1994 21:21:25 GMT Received: from sheila by igor.Rational.COM (4.1/smh-1.0) id AA05852; Thu, 27 Oct 94 14:21:39 PDT Message-Id: <9410272121.AA05852@igor.Rational.COM> Date: Thu, 27 Oct 94 14:14:53 PDT From: swb@Rational.COM To: ada9x-mrt@inmet.com Cc: swb@igor Subject: ada9x query Hop-Count: 1 !topic dispatching operations and renames !reference AARM-8.5.4;5.0 !from Stephen Baird <> !discussion If a subprogram which has controlling parameters is renamed by a renaming-as-declaration, are the corresponding parameters of the rename also controlling parameters? Can a call to the rename be a dispatching call? Is the rename a "dispatching operation"? However controlling formal parameters are treated, I assume that controlling result types are treated analogously. If a subprogram which is not a dispatching operation is renamed, can the rename be a dispatching operation? See example below. My understanding is that, in a chain of subprogram renames, the "controllingness" of a given formal parameter is a "sticky" attribute, in the sense that a parameter which is not controlling at the start of the chain may become controlling somewhere in the middle of the chain and from that point on in the chain it will remain controlling. Is this correct? (I am speaking imprecisely here, referring to the set of corresponding formal parameters in a chain of subprogram renames as one parameter, but I hope I am making myself clear). For example: package P is type T1 is tagged null record; package Q is type T2 is tagged null record; package R is procedure Foo (X1 : T1; X2 : T2); -- not a dispatching operation? end R; procedure Ren1 (X1 : T1; X2 : T2) renames R.Foo; -- 2nd parameter is controlling formal parameter? end Q; procedure Ren2_A (X1 : T1; X2 : Q.T2) renames Q.R.Foo; -- 1st parameter is controlling formal parameter? procedure Ren2_B (X1 : T1; X2 : Q.T2) renames Q.Ren_1; -- illegal by 3.9.2(12) ? package S is procedure Ren3 (X1 : P.T1; X2 : P.Q.T2) renames P.Q.R.Foo; -- not a dispatching operation? procedure Ren4 (X1 : P.T1; X2 : P.Q.T2) renames P.Q.Ren1; -- 2nd parameter is controlling formal parameter? procedure Ren5 (X1 : P.T1; X2 : P.Q.T2) renames P.Q.Ren2_A; -- 1st parameter is controlling formal parameter? procedure Ren6 (X1 : P.T1; X2 : P.Q.T2) renames P.Q.Ren2_B; -- illegal (because P.Q.Ren2_B was illegal)? end S; end P; From bobduff@dsd.camb.inmet.com Thu Oct 27 23:05:26 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA21931; Thu, 27 Oct 94 23:05:26 EDT Received: from dsd.camb.inmet.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA29956; Thu, 27 Oct 94 23:05:25 EDT Received: by dsd.camb.inmet.com (4.1/SMI-4.1) id AA21928; Thu, 27 Oct 94 23:05:22 EDT Date: Thu, 27 Oct 94 23:05:22 EDT From: bobduff@dsd.camb.inmet.com (Bob Duff) Message-Id: <9410280305.AA21928@dsd.camb.inmet.com> To: abg@SEI.CMU.EDU Cc: ada9x-mrt@inmet.com In-Reply-To: <199410262102.RAA24774@ts4c.sei.cmu.edu> (message from Anthony Gargaro on Wed, 26 Oct 94 17:02:05 EDT) Subject: Re: Question on children of generics !topic Children of Generics are Broken !reference RM9X-10.1.1(18-21);5.0 !reference RM9X-10.1.6(6);5.0 !reference 94-4933.a Tucker Taft 94-10-25 !reference 94-4953.a Anthony Gargaro 94-10-26 <> !discussion > > 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. > > Is the following construction allowed? > > generic package P is ... > > generic package P.A is ... > > with P.A; > generic package P.B is > package Legal is new P.A; Yes, this is legal. > The intent is to allow Legal to access the same parent instantiation as its > instantiator. In other words, the parent name within the declarative region > of a generic child denotes the current instantiation of the parent. Right. P.B is within the declarative region of P, and so the name P denotes the current instance of the parent. This current instance has a nested generic unit P.A, and the "with P.A;" causes that generic unit to be visible. So, you can instantiate it. - Bob