From stt@dsd.camb.inmet.com Thu May 26 02:03:33 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA02449; Thu, 26 May 94 02:03:33 EDT Received: from dsd.camb.inmet.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA21160; Thu, 26 May 94 02:03:31 EDT Received: from spock.camb.inmet.com.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA02446; Thu, 26 May 94 02:03:30 EDT Date: Thu, 26 May 94 02:03:30 EDT From: stt@dsd.camb.inmet.com (Tucker Taft) Message-Id: <9405260603.AA02446@dsd.camb.inmet.com> To: ada9x-mrt@inmet.com Subject: Minor comments on Section 9 (part 1) !topic Task activation description needs clarification !reference RM9X-9.2(1-6);4.0 !from Tucker Taft 94-05-25 <> !discussion The description of task activation is a bit confusing, particularly because the default initialization of an object might itself involve the (nested) evaluation of allocators. Some rewording might help a bit. !topic Entry queue servicing !reference RM9X-9.5.3(5-16);4.0 !from Tucker Taft 94-05-25 <> !discussion The description of entry calls and entry queue servicing is not always clear about what happens when. Also terms are italicized, but there is no clear definition of the term given (such as "servicing" an entry queue, or "selecting" an entry call). !topic Clarify selection of a delay alternative !reference RM9X-9.7.1(12);4.0 !from Tucker Taft 94-05-25 <> !discussion The description of how a delay alternative of a selective accept statement is selected is a bit unclear, and uses the future tense inappropriately. From Magnus.Kempe@di.epfl.ch Thu May 26 04:30:52 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA05201; Thu, 26 May 94 04:30:52 EDT Received: from sicmail.epfl.ch by inmet.camb.inmet.com (4.1/SMI-4.1) id AA01985; Thu, 26 May 94 04:30:47 EDT Received: from lglsun.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <22304-0@sicmail.epfl.ch>; Thu, 26 May 1994 10:30:20 +0200 Received: from lglsun4.epfl.ch by lglsun.epfl.ch (4.1/Epfl-4.5-c/MX) id AA25105; Thu, 26 May 94 10:30:18 +0200 Date: Thu, 26 May 94 10:30:18 +0200 From: Magnus.Kempe@di.epfl.ch (Magnus Kempe) Message-Id: <9405260830.AA25105@lglsun.epfl.ch> To: ada9x-mrt@inmet.com Subject: Checked Conversions Cc: dewar@cs.nyu.edu !topic Checked conversions with 'Valid !reference rm9x-13.9.1;4.0 !reference rm9x-13.9;4.0 !reference rm9x-3.5;4.0 !from Magnus Kempe 94-05-26 <> !discussion In comp.lang.ada, dewar@cs.nyu.edu (Robert Dewar) writes: : So in 9X, the proper idiom is: : : Do the conversion : Check the result using 'Valid : If 'Valid succeeds, steam on and use the value : If 'Valid fails, take appropriate error response, and do NOT use the : invalid value in any other operation. It would be interesting to abstract this pattern and create the following generic unit (keeping in mind that 'Valid is only defined for scalar objects, but there could be user-defined Valid functions): generic type Source is private; type Target is private; with function Valid (X : Target) return Boolean; function Checked_Conversion (S : Source) return Target; with Ada.Unchecked_Conversion; function Checked_Conversion (S : Source) return Target is function UC is new Ada.Unchecked_Conversion (Source, Target); T : Target renames UC (S); begin if Valid (T) then -- should be T'Valid, but that's illegal here return T; else raise Constraint_Error; end if; end Checked_Conversion; ... type Enum is (A, B, C); for Enum use (10, 20, 30); function CC is new Checked_Conversion (Integer, Enum, Enum'Valid); E1 : Enum := CC (20); -- succeed E2 : Enum := CC (21); -- fail ... The only problem is that there is no such thing as Enum'Valid; it's not defined as a function, unlike Enum'Succ, Enum'Image, etc. 'Valid takes an object as prefix. Is there any problem in changing that? Otherwise there is no way to provide a generic unit which applies 'Valid to scalar objects, since there is no "generic formal scalar type" mechanism. Magnus Kempe From Magnus.Kempe@di.epfl.ch Thu May 26 04:36:07 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA05269; Thu, 26 May 94 04:36:07 EDT Received: from sicmail.epfl.ch by inmet.camb.inmet.com (4.1/SMI-4.1) id AA02180; Thu, 26 May 94 04:36:00 EDT Received: from lglsun.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <22519-0@sicmail.epfl.ch>; Thu, 26 May 1994 10:35:49 +0200 Received: from lglsun4.epfl.ch by lglsun.epfl.ch (4.1/Epfl-4.5-c/MX) id AA25133; Thu, 26 May 94 10:35:48 +0200 Date: Thu, 26 May 94 10:35:48 +0200 From: Magnus.Kempe@di.epfl.ch (Magnus Kempe) Message-Id: <9405260835.AA25133@lglsun.epfl.ch> To: ada9x-mrt@inmet.com Subject: Index Wide_Character Cc: dewar@cs.nyu.edu !topic Index Wide_Character !reference rm9x-index;4.0 !reference rm9x-2.1;4.0 !reference rm9x-3.5.2;4.0 !from Magnus Kempe 94-05-26 <> !discussion The discussion of what type Wide_Character is is not indexed (C.1 is the package Standard, but 2.1 and 3.5.2 are more interesting). I think the same goes for type Character. Magnus Kempe From kst@alsys.com Thu May 26 05:19:18 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA05411; Thu, 26 May 94 05:19:18 EDT Received: from pet.alsys.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA04208; Thu, 26 May 94 05:19:07 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by pet.alsys.com (4.1/SMI-4.1.1) id AA28618; Thu, 26 May 94 02:18:50 PDT Received: from pulsar.alsys.com by rasht.alsys.com (4.1/TS-1.2b) id AA07363; Thu, 26 May 94 02:19:02 PDT Received: by pulsar.alsys.com (5.0/SMI-SVR4) id AA29901; Thu, 26 May 1994 02:19:00 +0800 Date: Thu, 26 May 1994 02:19:00 +0800 From: kst@alsys.com (Keith Thompson @pulsar) Message-Id: <9405260919.AA29901@pulsar.alsys.com> To: ada9x-mrt@inmet.com Subject: No parens need for abs, Paragraph numbers Content-Length: 1164 !topic No parens need for abs !reference RM9X-D.8(16);4.4 !reference 94-4323.e Bob Duff 94-5-25 !from Keith Thompson <> !discussion Bob Duff says "TS < abs(1.0)" probably meant "abs(TS) < 1.0". Better yet, make it "abs TS < 1.0". No parentheses are needed for the abs operator. (They're not incorrect, of course, but it's a good idea to avoid clutter, IMHO). !topic Paragraph numbers !reference RM9X-D.8(16,32);4.4 !reference 94-4323.e Bob Duff 94-5-25 !from Keith Thompson <> !discussion Bob Duff refers to paragraph 16 of section D.8. In the file I'm reading, rm9x.doc, the text he quotes is in paragraph 32; paragraph 16 is the declaration of type Ada.Real_Time.Seconds_Count. It's the same way in the PostScript version of the AARM. Is there a discrepency in the PostScript RM9X (which I don't have a copy of at the moment), or is it just a typo? This problem occurs with most or all of the paragraphs Bob Duff refers to in RM9X-D.8;4.4. -- Keith Thompson (The_Other_Keith) kst@alsys.com TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc. 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 Press any key to continue. Press any other key to quit. From dan@irvine.com Thu May 26 06:49:01 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA05630; Thu, 26 May 94 06:49:01 EDT Received: from laurel.irvine.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA08281; Thu, 26 May 94 06:48:57 EDT Received: from laurel.irvine.com by laurel.irvine.com with SMTP id AA16806 (5.65c/IDA-1.4.4 for ); Thu, 26 May 1994 03:49:07 -0700 Message-Id: <199405261049.AA16806@laurel.irvine.com> To: ada9x-mrt@inmet.com Cc: dan@irvine.com Subject: remove smileys from RM9X :) Date: Thu, 26 May 1994 03:49:06 PDT From: Dan Eilers !topic remove smileys from RM9X :) !reference RM9X-3.5.9(9);4.4 !from Dan Eilers 94-05-25 <> !discussion The vast majority of references in RM9X are of the form "(see 9.8)" or "(see B)", or "as described in A.11.4". However, there are some exceptions that should probably be made consistent (partial list). 3.5.9(9): (see the Information Systems Annex) -- full name 4.9(36): (see Annex G). -- Annex 6.(2): (see Section 9). -- Section 7.2(5): (see Section 10) -- Section A.8.2(1): described in subclause A.9.2. -- subclause 3.9.1(9): (of types defined above in 3.9:) -- smiley 4.3.1(30: (see 3.9 and 3.9.1:) -- smiley -- Dan From dan@irvine.com Thu May 26 06:50:17 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA05687; Thu, 26 May 94 06:50:17 EDT Received: from laurel.irvine.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA08359; Thu, 26 May 94 06:50:15 EDT Received: from laurel.irvine.com by laurel.irvine.com with SMTP id AA16832 (5.65c/IDA-1.4.4 for ); Thu, 26 May 1994 03:50:28 -0700 Message-Id: <199405261050.AA16832@laurel.irvine.com> To: ada9x-mrt@inmet.com Cc: dan@irvine.com Subject: floating-point underflow Date: Thu, 26 May 1994 03:50:28 PDT From: Dan Eilers !topic floating-point underflow !reference RM9X-Index;4.4 !from Dan Eilers 94-05-25 <> !discussion floating-point underflow should have an Index entry. (maybe some text too). -- Dan From agargaro@isd.csc.com Thu May 26 08:27:51 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA06664; Thu, 26 May 94 08:27:51 EDT Received: from isd.csc.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA13020; Thu, 26 May 94 08:27:47 EDT Date: Thu, 26 May 94 08:36:12 EDT From: agargaro@isd.csc.com (Anthony Gargaro) Received: by isd.csc.com (4.1/3.1.012693-Computer Sciences Corp.); id AA17280 for ada9x-mrt@inmet.com; Thu, 26 May 94 08:36:12 EDT Message-Id: <9405261236.AA17280@isd.csc.com> To: ada9x-mrt@inmet.com, agargaro@isd.csc.com Subject: multi-partition programs vs. distributed systems !topic multi-partition programs vs. distributed systems !reference RM9X-E;4.4 !reference 94-4312.a Dan Eilers 94-5-25 !from Anthony Gargaro 94-05-26 <> !discussion > The description of multi-partition programs in RM9X seems > biased toward distributed systems consisting of multiple > processing and/or storage nodes. This is correct. These systems are inadequately supported by the current language; this has lead to vendor-specific implementations. Therefore, support for loosely-coupled distributed systems is an underlying requirement for the Distributed Systems Annex. > I would contend that just as most multi-task programs > are implemented by interleaving on a single processor > rather than on multiple processors, many (if not most) > multi-partition programs will be implemented with multiple > address spaces on a virtual-address single processor, rather > than on multiple nodes. The specifications in Annex E do not preclude the implementation of a multi-partition program on a single processing node. This form of implementation is described in 10(1) "A program is a set of partitions, each of which may execute in a separate address space, possibly on a separate computer." > It would be nice to see at least a token mention of the > term "address space" in Annex E. Earlier versions of the Annex did use the term "common address space modules". The terms "processing node" and "storage node" have been introduced to avoid the potential confusion in using the word "module" and to relate the partitioning model to its "virtual node" heritage. A storage node is defined as "storage addressable by one or more processing nodes." This is meant to convey the include notion of a "common address space." From jb@ddci.dk Thu May 26 09:09:40 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA10496; Thu, 26 May 94 09:09:40 EDT Received: from dkuug.dk by inmet.camb.inmet.com (4.1/SMI-4.1) id AA15265; Thu, 26 May 94 09:09:35 EDT Received: from ddci.dk by dkuug.dk with UUCP id AA12711 (5.65c8/IDA-1.4.4j for ada9x-mrt@inmet.com); Thu, 26 May 1994 15:09:21 +0200 Received: by ddci.dk (4.0/j1.1.2) id AA09436; Thu, 26 May 94 13:05:55 +0200 Date: Thu, 26 May 94 13:05:55 +0200 From: jb@ddci.dk (Jorgen Bundgaard) Message-Id: <9405261105.AA09436@ddci.dk> To: ada9x-mrt@inmet.com Subject: Name Resolution Rules for Attribute_References X-Charset: ASCII X-Char-Esc: 29 !topic Name Resolution Rules for Attribute_References !reference AARM-4.1.4(6);4.4 !reference AARM-8.6(28);4.4 !from Jorgen Bundgaard 94-05-26 !keywords name resolution rules, attribute_reference, static expression <> !discussion I cannot find the rules which allow me to use the value of a static_expression in overload resolution. Consider the example: type T is ...; A : array( Character, Boolean ) of ... ; function F( X : Character ) return T; -- f1 function F( X : Boolean ) return T; -- f2 ... V : T := F( A'First( 1 ) ); -- F = f1 ? The problem is to show (formally) that there is one acceptable interpretation of the complete context containing F( A'First( 1 ) ). By using the syntax rules and the visibility rules, as required by 8.6(3 and 14), I get two the possible interpretations of A'First(1): An attribute_reference with the resulting type Character An attribute_reference with the resulting type Boolean Both interpretations obey the name resolution rules in 4.1.4(6), so I have two acceptabe interpretations, and overloading of F cannot be solved. Have I overlooked or misunderstood some rules? Aside: All the compilers I am aware of does resolve F to f1, presumably by locking the type of A'First( 1 ) to Character - based on an evaluation of the expression in the parentheses - and then eliminating f2 in the bottom-up part of overload resolution. I have always wondered whether overload resolution really did (in some cases) require evaluation of static expressions (which itself requires overload resolution)... From bobduff@dsd.camb.inmet.com Thu May 26 11:36:10 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA24452; Thu, 26 May 94 11:36:10 EDT Received: from dsd.camb.inmet.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA23228; Thu, 26 May 94 11:36:09 EDT Received: by dsd.camb.inmet.com (4.1/SMI-4.1) id AA24412; Thu, 26 May 94 11:36:08 EDT Date: Thu, 26 May 94 11:36:08 EDT From: bobduff@dsd.camb.inmet.com (Bob Duff) Message-Id: <9405261536.AA24412@dsd.camb.inmet.com> To: ada9x-mrt@inmet.com Subject: Comments on SP annex. !topic Single protected objects? !reference RM9X-G.3.1(6);4.0 !from Bob Duff <> !discussion Presumably, the rule should apply to a single_protected_declaration as well. !topic The [C]{c}orresponding !reference RM9X-G.3.1(7);4.0 !from Bob Duff <> From dritz@mcs.anl.gov Thu May 26 15:06:45 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA19963; Thu, 26 May 94 15:06:45 EDT Received: from antares10.mcs.anl.gov (antares9.mcs.anl.gov) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA03325; Thu, 26 May 94 15:06:37 EDT Received: from mcs.anl.gov (papasun.mcs.anl.gov [140.221.6.132]) by antares10.mcs.anl.gov (8.6.4/8.6.4) with ESMTP id OAA03400; Thu, 26 May 1994 14:06:29 -0500 Message-Id: <199405261906.OAA03400@antares10.mcs.anl.gov> To: ada9x-mrt@inmet.com Cc: squire@tron.wec.com Subject: Minor correction to Text_IO.Complex_IO.Get X-Mailer: MH 6.8 Date: Thu, 26 May 1994 14:06:27 -0500 From: Ken Dritz !topic Minor correction to Text_IO.Complex_IO.Get !reference RM9X-K.1.3(5);4.0 !reference 94-4169.a Jon Squire 94-05-05 !reference 94-4186.a Ken Dritz 94-05-09 !from Ken Dritz 94-05-26 <> !discussion Text_IO.Complex_IO.Get has already been changed slightly as a result of the comments referenced above. A further slight change is made, correcting a minor error in RM9X-K.1.3(5);4.0 that went unnoticed until now. The cited paragraph says that the real and imaginary components must be separated on the external medium by at least one blank when the comma is omitted. It should also allow the separation to consist of line terminators alone, if the value of the parameter Width is zero. From baker@ada.cs.fsu.edu Thu May 26 17:41:30 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA00946; Thu, 26 May 94 17:41:30 EDT Received: from ada.cs.fsu.edu by inmet.camb.inmet.com (4.1/SMI-4.1) id AA11401; Thu, 26 May 94 17:41:23 EDT Received: by ada.cs.fsu.edu (5.65/56) id AA01849; Thu, 26 May 94 17:40:43 -0400 Date: Thu, 26 May 94 17:40:43 -0400 From: Ted Baker Message-Id: <9405262140.AA01849@ada.cs.fsu.edu> To: ada9x-mrt@inmet.com Subject: RT Annex !topic Delete all but first sentence. !reference RM9X-D.5(14);4.4 !reference 94-4321.h Bob Duff 94-5-25 !from Ted Baker <> !discussion | The rest is not of interest. There is no paragraph (14) in D.4. Does this refer to (15)? If so, the information about not being on an entry queue and not executing a protected operation is of interest. If simpler wording is desired, one could say something more directly related to the intent, i.e. that priority change is not deferred for the affected task, and the priority change does not require reordering of an entry queue. !topic Bogus metrics !reference RM9X-D.6(6);4.4 !reference 94-4321.k Bob Duff 94-5-25 !from Ted Baker <> !discussion | Most of the Metrics are bogus for one reason or another (IMHO). [I find this remark offensive. The "bogosity" cited below is the result of cumulative effect of "editorial" wording changes, made without consulting the original author, which I fear you are about to aggravate, by making more of the same. :-(] | We ought to fix some of the most egregious offenders. | This one requires documentation of an upper bound when | there is no requirement that there even *be* an upper | bound. Add "if any". That would significantly change the intended meaning. This *is* the requirement (implicit) for an upper bound on the effect of abortion, but I see someone has taken the liberty of strengthening the rest of the wording, so that it would be impossible to bound. In the last draft I touched, it said | | On a multiprocessor, an upper bound, in seconds, on the time that | | the effect of abortion can be delayed beyond the point that it is | | required to take effect for a single processor. I don't mind the change in time unit from seconds to clock cycles, but replacing "take effect" by "complete the task", the entire meaning has been changed. [I recall once writing a definition of the phrase "take effect" for abortion. I suspect the definition has long disappeared.] The intent was that the "effect" to be measured here is the first point at which the flow of control of the target task is affected (modified) by the abortion. This is WELL before task completion, since we are talking here about the asynchronous abort as well as whole-task abortion. If there is finalization code associated with the ATC, it would be the point at which the first finalization handler starts to execute. !topic recognizing additional delays !reference RM9X-D.6(9);4.4 !reference RM9X-D.6(11);4.4 !reference 94-4321.l Bob Duff 94-5-25 !from Ted Baker <> !discussion | It's not clear what it means to "recognize" a delay. | In any case, the permission of D.6(9) is vacuous, since there is | no requirement on multi-processor implementations in this | clause anyway. At most, this should be a NOTE. That word "recognize" is another problem created by somebody's "editorial" change. Looking at an older copy of the ".mss" file, I have: | | On a system with multiple physical processors, there may be some | | additional delay for interprocessor communication, but this | | additional delay shall be bounded. | D.6(11) is silly. Of course it's desirable to bound the delay. [I find this remark offensive. Moreover, it demonstrates the person making the remark has assumed responsibility for editing this annex sithout bothering to read the rationale, much less consult with the original author. This is very disturbing. :-(] | But whether or not that's feasible depends on the hardware's | ability to allow one processor to interrupt another one in | bounded time. If the hardware can't do it, our advice to the | compiler vendor is not going to do any good. The intent is to recommend that a polling strategy be used, if necessary, to check for pending aborts. This can be done on any processor that can implement time delays. The polling interval can be made long enough that the overhead is not excessive. This is clearly stated in the Rationale, which I quote: "Note that the requirement for bounding the delay in achieving the effect of abortion can be satisfied on a multiprocessor, even if it is not possible for one processor to interrupt another. One technique is to use a periodic timer-generated interrupt on each processor, which causes the processor to check whether the currently executing task has become abnormal." !topic No_Nested_Finalization !reference RM9X-D.7(4);4.4 !reference 94-4321.m Bob Duff 94-5-25 !from Ted Baker <> !discussion | This restriction should include everything that has nontrivial | finalization, not just controlled objects. | In particular, it should include protected objects with entries. This is counter to what I thought was the intent of the restriction, i.e., to bound the time for abortion, by preventing the execution of USER-DEFINED finalization routines. While protected objects with entries do require a check for pending calls, this is not necessarily implemented using a controlled type, and should have a predictable execution time (if one knows an upper bound on the number of calls that might still be on the queues --- hopefully zero!). !topic Redundancy with 13.12 !reference RM9X-D.7;4.4 !reference 94-4321.o Bob Duff 94-5-25 !from Ted Baker <> !discussion | This clause has several tidbits of information that are redundant | with 13.12, but not enough so that the reader can tell what's | going on without reading 13.12. Either remove the redundancy, or | beef it up. This statement is rather vague, as it applies to a whole section. I am worried about the implementation, given the effects of other "editorial" changes. !topic Clarify Max_Tasks !reference RM9X-D.7(20);4.4 !reference 94-4321.q Bob Duff 94-5-25 !from Ted Baker <> !discussion | Clarify the wording so that D.7(20.a) is really true. I don't see D.7(20) can be construed as "true" or "false", since it is a definition. Max_Tasks Specifies the maximum number of tasks, excluding the environment task, that are allowed to exist over the lifetime of the partition. If it is not clear, the intent is that this be an upper bound on the cumulative number of task creations. On some implementations, each task has a unique ID, and IDs are not (intentionally) recycled. Thus, when the count overflows the size of the counter (say 32 bits), the system either bombs, or one ends up with a possibility of duplicate task IDs. [Another interesting bound would be on the maximum number of tasks that can exist at one time, but that is not the intent here. I would recommend that restriction might also be given a name.] !topic Awkward wording !reference RM9X-D;4.4 !reference 94-4321.s Bob Duff 94-5-25 !from Ted Baker <> !discussion More awkward wording / grammar problems in real-time annex: ... | D.4(14) What is the problem here? | D.5(4,5,8,12) These are in the package specification of Ada.Dynamic Priorities. What is the "wording / grammar problem" there? !topic distance inappropriate !reference RM9X-D.8(8);4.4 !reference 94-4323.b Bob Duff 94-5-25 !from Ted Baker <> !discussion | The term "distance" doesn't make sense here -- we're talking about time. There must be an error in the reference. D.8(8) is part of the package specification of Ada.Real_Time. I guess you mean D.8(24). I recommend the wording be: A value of type Seconds_Count represents an elapsed time, measured in seconds, since the epoch. !topic Simplify wording of To_Duration and To_Time_Span !reference RM9X-D.8(11);4.4 !reference 94-4323.d Bob Duff 94-5-25 !from Ted Baker <> !discussion | This would be simpler as, "To_Duration(Time_Span_Zero) returns 0.0, | and To_Time_Span(0.0) returns Time_Span_Zero". This seems fine, but you must be working from a different document than the ARM4.4 that is on the AJPO host. On my copy, paragraph (11) is in the package specification of Ada.Real_Time. I guess you are referring to paragraph (27) on my copy. This mis-match of paragraph numbers is troubling, if it means other comments being circulated are also misdirected. !topic abs(1.0) is 1.0 !reference RM9X-D.8(16);4.4 !reference 94-4323.e Bob Duff 94-5-25 !from Ted Baker <> !discussion I guess this refers to D.8(32). | "TS < abs(1.0)" probably meant "abs(TS) < 1.0". I don't know where the requirement "TS < abs(1.0)" (or "abs(TS) < 1.0") came from, or why. I also fail to see why the following sentence, about the inverse mathematica mapping, needs to be in normative text. Why not just say: The value returned by Time_Of(SC,TS) is the value T such that T*Time_Unit = SC*1.0+TS*Time_Unit. By the way, I am thinking some inaccuracy should be allowed in this computation (so the functions might not be inverses). It could be that Time_Unit is not a nice fraction, e.g. one second cannot be represented exactly as an integral multiple of Time_Units. !topic Use time base instead of clock source. !reference RM9X-D.8(24);4.4 !reference 94-4323.f Bob Duff 94-5-25 !from Ted Baker <> I guess this refers to D.8(40). It is not clear that there is any "time base". The source might be operator input, or it might just be initialized to zero when the system cold-boots. !topic Strange rule. !reference RM9X-D.8(26);4.4 !reference 94-4323.g Bob Duff 94-5-25 !from Ted Baker <> !discussion I can't guess which paragraph this refers to. By cumulative offsets, I first guessed maybe (42), but then what is "(26.a)"? | It seems very strange to set up a bunch of "shall" rules, | and then say that the implementation has to document any | that it doesn't obey. (26.a) explains what's really going | on. There's got to be a better way to word this. I'll assume this is talking about (42), which asks for documentation of AI-325 cases, where the implementation is unable to comply with one of the earlier requirements. !topic Tick should be Clock. !reference RM9X-D.8(39);4.4 !reference 94-4323.h Bob Duff 94-5-25 !from Ted Baker <> !discussion My best guess for which paragraph is meant here is number (53) on my copy, which says When appropriate, implementations should provide configuration mechanisms to change the value of Tick. This definitely means "Tick", and not "Clock". The intent is to allow for the ability of a user/installer to change the rate at which the hardware clock source used by the Ada implementation ticks. | ...and in (41), "the clock tick" should probably be "Tick". In that case, you are probably right, though I am not sure, since did not write that sentence. If it does not really mean the resolution of the best clock source (which doesn't make much more sense), then it should probably be "Real_Time.Clock", rather than just "Clock". !topic Awkward wording !reference RM9X-D;4.4 !reference 94-4323.i Bob Duff 94-5-25 !from Ted Baker <> !discussion | D.8(13,14) | D.12(9) I can't match these paragraph numbers up with anything meaningful on my copy of RM9X 4.4. Before you go making "editorial" changes, I hope you might confer with one of the authors. From stt@dsd.camb.inmet.com Thu May 26 18:44:36 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA02791; Thu, 26 May 94 18:44:36 EDT Received: from dsd.camb.inmet.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA13692; Thu, 26 May 94 18:44:33 EDT Received: from spock.camb.inmet.com.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA02787; Thu, 26 May 94 18:44:31 EDT Date: Thu, 26 May 94 18:44:31 EDT From: stt@dsd.camb.inmet.com (Tucker Taft) Message-Id: <9405262244.AA02787@dsd.camb.inmet.com> To: ada9x-mrt@inmet.com Subject: View conversion need not include actual IN parameters !topic View conversions and static expressions !reference RM9X-4.6(5);4.0 !reference RM9X-4.9(10);4.0 !from Tucker Taft 94-05-26 <> !discussion Currently a view conversion can be a static expression under certain circumstances. This makes the description of when a type_conversion is static more complicated, because it needs to include a parenthetical comment "(or a that statically denotes a static constant)". We can eliminate this case by revising the definition of view conversion so that it only includes actual parameters of mode OUT and IN OUT. This seems more intuitive anyway (and it should make no difference at all to implementors in any case). Actual IN parameters were originally included in view conversions to make the notion of by-reference parameter passing reasonable when the actual was a non-representation-changing conversion. However, we need in any case to define the object associated with a value of a by-reference type, because it is legal to pass as an IN parameter a qualified expression (which is officially a "value," not an object). We have already added words to define the object associated with a by-reference value in 6.2, so there is no remaining reason to consider conversions used as actual IN parameters to be view conversions. This change allows us to drop the parenthetical statement in 4.9(10). !topic Static constants and renames !reference RM9X-4.9(6,24);4.0 !from Tucker Taft 94-05-26 <> !discussion The current definitions of potentially static expressions and static constants has an unintentional anomaly that a name that denotes an object_renaming_declaration that renames an anonymous constant object whose value is static, is not itself static. This can be most easily repaired by "inlining" the definition of static constant into 4.9(6), and reorganizing things a bit so that all static expressions that are syntactically s are grouped together. As a result of this change and the one above about view conversions, we can drop the term "static constant" completely (yeah! -- one less italicized term ;-). From dan@irvine.com Thu May 26 19:05:00 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA04002; Thu, 26 May 94 19:05:00 EDT Received: from laurel.irvine.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA14652; Thu, 26 May 94 19:04:30 EDT Received: from laurel.irvine.com by laurel.irvine.com with SMTP id AA25900 (5.65c/IDA-1.4.4 for ); Thu, 26 May 1994 16:04:20 -0700 Message-Id: <199405262304.AA25900@laurel.irvine.com> To: ada9x-mrt@inmet.com Cc: dan@irvine.com Subject: dynamic semantics of predefined operators Date: Thu, 26 May 1994 16:04:19 PDT From: Dan Eilers !topic dynamic semantics of predefined operators !reference RM9X-4.5;4.4 !from Dan Eilers 94-05-26 <> !discussion Where exactly are the dynamic semantics defined? 4.5(9) (Static Semantics) says: The predefined operators and their effects are described in subclauses 4.5.1 through 4.5.6. However, neither 4.5.4 nor 4.5.6 has a Dynamic Semantics section. 4.5(10) (as opposed to 4.5.1 through 4.5.6) says: The predefined operations on integer types either yield the mathematically correct result or raise the exception Constraint_Error. This seems way too permissive, or at best misleading. RM83 followed this sentence with a clarifying requirement to raise Numeric_Error only if the result was not a value of the type. Since 9X doesn't retain this requirement (at least not explicitly), is an implementation allowed to arbitrarily raise Constraint_Error for predefined integer operations? -- Dan p.s. my (unanswered) comments 94-3636.a and 94-3637.a about the wrong precedence of unary minus with respect to mod could be addressed by an example in this section showing that: "-12 mod 5" is parsed as "-(12 mod 5)" which is -2. This differs from "(-12) mod 5" which is 3. From gary@alsys.com Thu May 26 21:06:13 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA05191; Thu, 26 May 94 21:06:13 EDT Received: from pet.alsys.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA19036; Thu, 26 May 94 21:06:06 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by pet.alsys.com (4.1/SMI-4.1.1) id AA00102; Thu, 26 May 94 18:05:45 PDT Received: from pulsar.alsys.com by rasht.alsys.com (4.1/TS-1.2b) id AA29735; Thu, 26 May 94 18:05:57 PDT Received: by pulsar.alsys.com (5.0/SMI-SVR4) id AA24279; Thu, 26 May 1994 18:05:54 +0800 Date: Thu, 26 May 1994 18:05:54 +0800 From: gary@alsys.com (Gary Dismukes @pulsar) Message-Id: <9405270105.AA24279@pulsar.alsys.com> To: ada9x-mrt@inmet.com Subject: Mentions of "ancestor part" Content-Length: 562 !topic Mentions of "ancestor part" !reference RM9X-4.3(6);4.4 !from Gary Dismukes 94-05-26 <> !discussion 4.3(6) refers to the "ancestor part" of an aggregate several times. In version 4.0 there wasn't a definition for an ancestor part, but in 4.4 it's now an explicit part of the syntax for extension aggregates. It seems that it should now be spelled with an underscore (i.e., ancestor_part) in this paragraph. Also, since this is a forward reference, it would be helpful to include a mention of section 4.3.2 in this paragraph (as does 4.3.1(9)). -- Gary From gary@alsys.com Thu May 26 21:06:50 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA05252; Thu, 26 May 94 21:06:50 EDT Received: from pet.alsys.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA19043; Thu, 26 May 94 21:06:41 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by pet.alsys.com (4.1/SMI-4.1.1) id AA00107; Thu, 26 May 94 18:06:18 PDT Received: from pulsar.alsys.com by rasht.alsys.com (4.1/TS-1.2b) id AA29738; Thu, 26 May 94 18:06:30 PDT Received: by pulsar.alsys.com (5.0/SMI-SVR4) id AA24420; Thu, 26 May 1994 18:06:28 +0800 Date: Thu, 26 May 1994 18:06:28 +0800 From: gary@alsys.com (Gary Dismukes @pulsar) Message-Id: <9405270106.AA24420@pulsar.alsys.com> To: ada9x-mrt@inmet.com Subject: Assignment of an ancestor_part Content-Length: 1321 !topic Assignment of an ancestor_part !reference RM9X-4.3(6);4.4 !reference RM9X-7.6;4.4 !reference RM9X-3.9.3(8);4.4 !from Gary Dismukes 94-05-26 <> !discussion 4.3(6) states that the ancestor part of an aggregate is assigned into the ancestor part of an anonymous object created at the place of the aggregate. This would seem to imply calling the Adjust operation if the type is controlled. However, if the ancestor_part is given by a subtype_mark, then it seems superfluous to call Adjust since Initialize has already been called for the ancestor part (unless Initialize is abstract). Elision of the call to Adjust should be allowed as an optimization, but the rules of 7.6 don't appear to cover this case. (And if a call to Adjust is needed, what if Adjust is an abstract procedure?) Also, there appears to be a semantic inconsistency in the case where the type of the ancestor_part is abstract. 3.9.3(8) states a new rule disallowing the target type of an assignment from being an abstract type. This would appear to make such aggregates illegal. Or is the assignment of the ancestor_part into the aggregate considered legal because it's actually assigning to (a part of) an object of a nonabstract type? If this latter interpretation is the intent, then what is the target type of the assignment?? -- Gary From gary@alsys.com Thu May 26 21:09:09 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA05315; Thu, 26 May 94 21:09:09 EDT Received: from pet.alsys.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA19049; Thu, 26 May 94 21:08:54 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by pet.alsys.com (4.1/SMI-4.1.1) id AA00120; Thu, 26 May 94 18:08:28 PDT Received: from pulsar.alsys.com by rasht.alsys.com (4.1/TS-1.2b) id AA29754; Thu, 26 May 94 18:08:40 PDT Received: by pulsar.alsys.com (5.0/SMI-SVR4) id AA25261; Thu, 26 May 1994 18:08:37 +0800 Date: Thu, 26 May 1994 18:08:37 +0800 From: gary@alsys.com (Gary Dismukes @pulsar) Message-Id: <9405270108.AA25261@pulsar.alsys.com> To: ada9x-mrt@inmet.com Subject: Comments on RM9X-4.3.1;4.4 Content-Length: 1181 !topic each component of the record {type} or record extension !reference RM9X-4.3.1(1);4.4 !from Gary Dismukes 94-05-26 <> !discussion !topic Suggestion for wording change !reference RM9X-4.3.1(1);4.4 !from Gary Dismukes 94-05-26 <> !discussion The phrase "using either named or positional associations" at the end of 4.3.1(1) sounds like it's mutually exclusive. Since record aggregates can mix named and positional associations it seems like a better wording might be "using either {a} named or {a} positional [associations] {association}." The use of the singular also reads better in conjunction with the earlier part of the sentence, which states that "a value is specified for each component ..." !topic Change '.' to ';' !reference RM9X-4.3.1(11);4.4 !from Gary Dismukes 94-05-26 <> !discussion I suggest changing the period at the end of 4.3.1(10) to a semicolon, for consistency with other bulleted lists of paragraphs. Check bulleted paragraphs in other sections as well, as I recall noticing some other cases of inconsistency. !topic Change ':)' to '):' !reference RM9X-4.3.1(30);4.4 !from Gary Dismukes 94-05-26 <> !discussion Move the colon outside the parentheses. From gary@alsys.com Thu May 26 21:10:51 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA05388; Thu, 26 May 94 21:10:51 EDT Received: from pet.alsys.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA19069; Thu, 26 May 94 21:10:47 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by pet.alsys.com (4.1/SMI-4.1.1) id AA00129; Thu, 26 May 94 18:10:28 PDT Received: from pulsar.alsys.com by rasht.alsys.com (4.1/TS-1.2b) id AA29800; Thu, 26 May 94 18:10:39 PDT Received: by pulsar.alsys.com (5.0/SMI-SVR4) id AA25703; Thu, 26 May 1994 18:10:38 +0800 Date: Thu, 26 May 1994 18:10:38 +0800 From: gary@alsys.com (Gary Dismukes @pulsar) Message-Id: <9405270110.AA25703@pulsar.alsys.com> To: ada9x-mrt@inmet.com Subject: Associations for additional components Content-Length: 404 !topic Associations for additional components !reference RM9X-4.3.2(1);4.4 !reference RM9X-4.3.2(6);4.4 !from Gary Dismukes 94-05-26 <> !discussion The statement that an extension aggregate gives "associations for any additional components not inherited from the ancestor" leaves out the possibility of associations for inherited discriminants in certain cases (which is discussed in 4.3.2(6)). -- Gary From gary@alsys.com Thu May 26 21:11:24 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA05446; Thu, 26 May 94 21:11:24 EDT Received: from pet.alsys.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA19081; Thu, 26 May 94 21:11:20 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by pet.alsys.com (4.1/SMI-4.1.1) id AA00136; Thu, 26 May 94 18:11:03 PDT Received: from pulsar.alsys.com by rasht.alsys.com (4.1/TS-1.2b) id AA29846; Thu, 26 May 94 18:11:15 PDT Received: by pulsar.alsys.com (5.0/SMI-SVR4) id AA25819; Thu, 26 May 1994 18:11:13 +0800 Date: Thu, 26 May 1994 18:11:13 +0800 From: gary@alsys.com (Gary Dismukes @pulsar) Message-Id: <9405270111.AA25819@pulsar.alsys.com> To: ada9x-mrt@inmet.com Subject: Uninherited discriminants Content-Length: 838 !topic Uninherited discriminants !reference RM9X-4.3.2(6);4.4 !from Gary Dismukes 94-05-26 <> !discussion 4.3.2(6) defines the components "needed" for the record_component _association of an extension_aggregate. It says that "the only components needed are those of the composite value defined by the aggregate that are not inherited from the type of the ancestor_part" (plus inherited discriminants in certain cases). This could be misunderstood to be saying that discriminants that are not inherited from the the ancestor type need to be represented in the association list, which is clearly not the intent. I'm not sure of the best way to reword this, but perhaps a similar phrasing to that used in 4.3.2(1) could be used (e.g., you could refer to "additional components not inherited from the type of the ancestor part"). -- Gary From rbrukardt@BIX.com Thu May 26 21:12:01 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA05507; Thu, 26 May 94 21:12:01 EDT Received: from bos1a.delphi.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA19087; Thu, 26 May 94 21:11:58 EDT Received: from bix.com by delphi.com (PMDF V4.2-14 #6563) id <01HCT3PRF6E895OIKH@delphi.com>; Thu, 26 May 1994 20:33:30 EDT Received: by bix.com (CoSy3.31.1.45) id <9405262030.memo.73386@BIX.com>; Thu, 26 May 1994 20:30:21 -0400 (EDT) Date: Thu, 26 May 1994 20:30:21 -0400 (EDT) From: rbrukardt@BIX.com Subject: Various To: ada9x-mrt@inmet.com Message-Id: <9405262030.memo.73386@BIX.com> Content-Transfer-Encoding: 7BIT X-Cosy-To: ada9x-mrt@inmet.com !topic Why only modular types here? !reference RM9X-4.6(33);4.4 !from Randy Brukardt (RR Software) 94-5-26 <> !discussion > 33 In the above numeric conversions, if the target type is a | > modular type, Constraint_Error is raised if the result is | > outside the base range of the target type. | Why does this rule apply only to modular types? It would seem to apply to all discrete types. Is there any advantage to allowing values outside of the base range for signed integer types? (It could only happen for a conversion like: Integer'Base(Expr) in any event, not exactly a likely case). I can see advantages to not having it apply to floating point types, although even there it might have a user advantage (that is, extra precision/range is not carried across a conversion). Indeed, the meaning of Float(Expr) is quite a bit different between Ada 83 and Ada 9x in this area. In any event, the rule as written seems like a special case kludge, when it really is the normal case for all scalar types (only unconstrained integers and floats can escape its effects). Randy. !topic 3.5.4(18) is empty, why does it have a number? !reference RM9X-3.5.4(18);4.4 !from Randy Brukardt (RR Software) 94-5-26 <> !topic Arrow is often pronounced "choose" !reference RM9X-2.2(14);4.4 !from Randy Brukardt (RR Software) 94-5-26 <> !discussion I know many Ada programmers call the "=>" symbol 'choose'. It would be helpful if that was noted in the RM. !topic Abstract operations of tagged types. !reference RM9X 3.9.3(7);4.4 !from Randy Brukardt (RR Software) 94-5-26 <> !discussion I cannot find any reference to my previous comments on this paragraph in the RM, so I don't know if my suggestions on that were rejected, or just missed. In any event, I still find the paragraph misleading. Para 7 says "A call on a abstract subprogram shall be a dispatching call." On causal reading, this says to me that calls on abstract subprograms are somehow dispatching. It does NOT imply a limitation, which is in actual fact what it defines. Now, of course, us language lawyers can get the correct meaning out of it, but it seems to me that the average advanced Ada user which is checking out this new area will get confused. Changing the rule to "The only calls on an abstract subprogram shall be dispatching calls." makes it clear(er?) that a limitation is being expressed. My real preference is "Calls on abstract subprograms are illegal unless they are dispatching calls", but I can't find a way to word that using 'shall'. I much prefer not having to depend on the introduction to get the correct meaning, particularly because I never read 'em. :-) Randy. !topic "Abs" has no description. !reference RM9X 4.5.6(1-2);4.4 !from Randy Brukardt (RR Software) 94-5-26 <> !discussion The "Abs" operator has no description of what it does, while the other operators in this section have several paragraphs each. Some other sections say that operators are "predefined, having their conventional meaning", but even that is omitted here. Something ought to be said, otherwise us implementors can start inventing creative meanings! :-) From gary@alsys.com Thu May 26 21:12:15 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA05564; Thu, 26 May 94 21:12:15 EDT Received: from pet.alsys.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA19093; Thu, 26 May 94 21:12:09 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by pet.alsys.com (4.1/SMI-4.1.1) id AA00142; Thu, 26 May 94 18:11:53 PDT Received: from pulsar.alsys.com by rasht.alsys.com (4.1/TS-1.2b) id AA29855; Thu, 26 May 94 18:12:05 PDT Received: by pulsar.alsys.com (5.0/SMI-SVR4) id AA25955; Thu, 26 May 1994 18:12:03 +0800 Date: Thu, 26 May 1994 18:12:03 +0800 From: gary@alsys.com (Gary Dismukes @pulsar) Message-Id: <9405270112.AA25955@pulsar.alsys.com> To: ada9x-mrt@inmet.com Subject: Evaluation of an ancestor_part Content-Length: 387 !topic Evaluation of an ancestor_part !reference RM9X-4.3.2(7);4.4 !from Gary Dismukes 94-05-26 <> !discussion Now that a subtype_mark can be given in an extension_aggregate, is it still correct to refer to the "evaluation" of the ancestor part? If yes, then it seems that an explicit definition of what it means to evaluate an ancestor_part given by a subtype_mark is needed. -- Gary From gary@alsys.com Thu May 26 21:12:56 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA05622; Thu, 26 May 94 21:12:56 EDT Received: from pet.alsys.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA19099; Thu, 26 May 94 21:12:50 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by pet.alsys.com (4.1/SMI-4.1.1) id AA00148; Thu, 26 May 94 18:12:30 PDT Received: from pulsar.alsys.com by rasht.alsys.com (4.1/TS-1.2b) id AA29861; Thu, 26 May 94 18:12:42 PDT Received: by pulsar.alsys.com (5.0/SMI-SVR4) id AA26063; Thu, 26 May 1994 18:12:40 +0800 Date: Thu, 26 May 1994 18:12:40 +0800 From: gary@alsys.com (Gary Dismukes @pulsar) Message-Id: <9405270112.AA26063@pulsar.alsys.com> To: ada9x-mrt@inmet.com Subject: Arbitrary order of evaluation in an extension_aggregate Content-Length: 551 !topic Arbitrary order of evaluation in an extension_aggregate !reference RM9X-4.3.2(7);4.4 !from Gary Dismukes 94-05-26 <> !discussion 4.3.2(7) says that "the ancestor_part and the record_component _association_list are evaluated in an arbitrary order." However, it seems that in the case of an ancestor_part given by a subtype name, it's necessary, in general, to evaluate the associations for inherited discriminants prior to "evaluating" the ancestor_part, since the default initialization may depend on the values of the discriminants. -- Gary From gary@alsys.com Thu May 26 21:13:54 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA05680; Thu, 26 May 94 21:13:54 EDT Received: from pet.alsys.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA19107; Thu, 26 May 94 21:13:47 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by pet.alsys.com (4.1/SMI-4.1.1) id AA00156; Thu, 26 May 94 18:13:25 PDT Received: from pulsar.alsys.com by rasht.alsys.com (4.1/TS-1.2b) id AA29868; Thu, 26 May 94 18:13:36 PDT Received: by pulsar.alsys.com (5.0/SMI-SVR4) id AA26218; Thu, 26 May 1994 18:13:34 +0800 Date: Thu, 26 May 1994 18:13:34 +0800 From: gary@alsys.com (Gary Dismukes @pulsar) Message-Id: <9405270113.AA26218@pulsar.alsys.com> To: ada9x-mrt@inmet.com Subject: Confusing sentence about ancestor_part initialization Content-Length: 1349 !topic Confusing sentence about ancestor_part initialization !reference RM9X-4.3.2(7);4.4 !reference RM9X-4.3.2(6);4.4 !from Gary Dismukes 94-05-26 <> !discussion The second half of the second sentence of 4.3.2(7) is awkward and difficult to understand. It sounds as if it's saying that implicit initial values are always determined by discriminants. Also, it's not clear to me how cases such as the following are intended to work: type T ( D1: Positive ) is tagged record S: String( 1 .. D ); end record; type NT ( D2: Boolean ) is new T( 10 ) with record I: Integer; end record; Obj: NT := ( T with D2 => True, I => 20 ); Since the discriminant D1 is not inherited for type NT, no component association can be given for it in the aggregate, (4.3.2(6) doesn't apply to noninherited discriminants). It's unclear how the ancestor_part of the aggregate will be initialized properly in this case. Presumably the ancestor_part should be initialized according to the constraint imposed in the type extension of NT. But 4.3.2(7) doesn't seem to support that, since it says "obtaining the implicit values as determined by the discriminants of the value of the aggregate" and it doesn't seem that D1 can be considered a discriminant of the aggregate value given that it isn't a component of type NT. -- Gary From gary@alsys.com Thu May 26 21:14:37 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA05739; Thu, 26 May 94 21:14:37 EDT Received: from pet.alsys.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA19139; Thu, 26 May 94 21:14:30 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by pet.alsys.com (4.1/SMI-4.1.1) id AA00164; Thu, 26 May 94 18:14:13 PDT Received: from pulsar.alsys.com by rasht.alsys.com (4.1/TS-1.2b) id AA29908; Thu, 26 May 94 18:14:25 PDT Received: by pulsar.alsys.com (5.0/SMI-SVR4) id AA26355; Thu, 26 May 1994 18:14:21 +0800 Date: Thu, 26 May 1994 18:14:21 +0800 From: gary@alsys.com (Gary Dismukes @pulsar) Message-Id: <9405270114.AA26355@pulsar.alsys.com> To: ada9x-mrt@inmet.com Subject: Discriminants of an ancestor_part Content-Length: 338 !topic Discriminants of an ancestor_part !reference RM9X-4.3.2(8);4.4 !from Gary Dismukes 94-05-26 <> !discussion The phrase "each discriminant of the ancestor_part" in 4.3.2(8) seems technically incorrect since ancestor_part is a syntactic entity. Perhaps this should say "each discriminant of the value of the ancestor_part." -- Gary From gary@alsys.com Thu May 26 21:15:39 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA05800; Thu, 26 May 94 21:15:39 EDT Received: from pet.alsys.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA19145; Thu, 26 May 94 21:15:29 EDT Received: from rasht.alsys.com (mailhub.alsys.com) by pet.alsys.com (4.1/SMI-4.1.1) id AA00168; Thu, 26 May 94 18:15:05 PDT Received: from pulsar.alsys.com by rasht.alsys.com (4.1/TS-1.2b) id AA00107; Thu, 26 May 94 18:15:17 PDT Received: by pulsar.alsys.com (5.0/SMI-SVR4) id AA26500; Thu, 26 May 1994 18:15:14 +0800 Date: Thu, 26 May 1994 18:15:14 +0800 From: gary@alsys.com (Gary Dismukes @pulsar) Message-Id: <9405270115.AA26500@pulsar.alsys.com> To: ada9x-mrt@inmet.com Subject: Note on Initialize for an ancestor_part Content-Length: 657 !topic Note on Initialize for an ancestor_part !reference RM9X-4.3.2(10);4.4 !reference RM9X-4.3.2(7);4.4 !reference RM9X-7.6;4.4 !from Gary Dismukes 94-05-26 <> !discussion The note in 4.3.2(10) asserts that Initialize will be called for a controlled ancestor_part given by a subtype_mark (if the procedure is not abstract). I don't see how this is backed up by any normative text in RM9X;4.4. 4.3.2(7) describes how components not specified by associations are initialized by default, but this doesn't imply that Initialize will be called for the ancestor_part as a whole. Subsection 7.6 doesn't seem to cover this either. What am I missing? -- Gary From rbrukardt@BIX.com Thu May 26 21:57:08 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA06121; Thu, 26 May 94 21:57:08 EDT Received: from bos1a.delphi.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA19432; Thu, 26 May 94 21:57:02 EDT Received: from bix.com by delphi.com (PMDF V4.2-14 #6563) id <01HCT3MOSKDC95OIKH@delphi.com>; Thu, 26 May 1994 20:31:02 EDT Received: by bix.com (CoSy3.31.1.45) id <9405262029.memo.73379@BIX.com>; Thu, 26 May 1994 20:29:14 -0400 (EDT) Date: Thu, 26 May 1994 20:29:14 -0400 (EDT) From: rbrukardt@BIX.com Subject: Static exprs To: ada9x-mrt@inmet.com Message-Id: <9405262029.memo.73379@BIX.com> Content-Transfer-Encoding: 7BIT X-Cosy-To: ada9x-mrt@inmet.com !topic Static expression base range checks !reference RM9X-3.5(6);4.4 !reference RM9X-4.9(35);4.4 !from Randy Brukardt (RR Software) 94-5-26 <> !discussion Checks are required if a static expression is outside of its base range in a non-static context. The use of the context here seems weird, and brings up some questions: 1) "If a scalar static expression is in a static context, its value MAY be outside the base range of its expected type..." Does this mean (looking at it from the implementor's perspective) that the implementation can allow it to be outside of the base range, or that the implementation MUST allow it to be outside of the base range? I don't believe there is any (other?) place where an implementation is required to support values outside of the base range, so if it MUST be allowed, that is weird. OTOH, 'can allow' seems non-portable. MUST allow would seem to allow non-sensical declarations like (assuming enough memory to evaluation the values): C1 : Constant Integer'Base := 9**500; -- OK I1 : Integer'Base := 9**500; -- Error C2 : Constant Integer'Base := 9**498; -- OK I2 : Integer'Base := C1 / C2; -- OK I note that implementing "MUST" is a problem in our implementation, since the context is not available at any of the convenient places to implement the check. 2) "If a scalar static expression is [not] in a static context..., its exact value shall be within the base range." This rule seems to disallow some very useful expressions: Type Modular Is Mod 2**16; Code1 : Modular := -1; -- Illegal(?) Code2 : Modular := Modular(-1); -- Illegal. Type Mod7 Is 7; Code3 : Mod7 := 9; -- Illegal. Code4 : Mod7 := 9 + 1; -- Illegal(?) (Value is 3 if evaluated) Code5 : Mod7 := 5 + 5; -- OK(?) (Value is 3 if evaluated) Code6 : Mod7 := Mod7(9 + 1); -- Illegal. Code7 : Mod7 := Mod7(5 + 5); -- Illegal. Is this intended? Randy. From dan@irvine.com Thu May 26 23:04:39 1994 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA07083; Thu, 26 May 94 23:04:39 EDT Received: from laurel.irvine.com by inmet.camb.inmet.com (4.1/SMI-4.1) id AA20180; Thu, 26 May 94 23:04:36 EDT Received: from laurel.irvine.com by laurel.irvine.com with SMTP id AA28592 (5.65c/IDA-1.4.4 for ); Thu, 26 May 1994 19:38:59 -0700 Message-Id: <199405270238.AA28592@laurel.irvine.com> To: ada9x-mrt@inmet.com Cc: dan@irvine.com Subject: conditional compilation Date: Thu, 26 May 1994 19:38:58 PDT From: Dan Eilers !topic conditional compilation !reference RM9X-Index;4.4 !from Dan Eilers 94-05-26 <> !discussion It would be nice to have an Index entry for conditional compilation, pointing to some text that says something like: Note: Ada has no provision for conditional compilation. This allows the legality of compilation units to be determined independently from compilation switches. -- Dan