!standard E.2.2 (08) 00-04-11 AI95-00126/10 !standard 7.06 (04) !standard A.5.1 (09) !standard G.1.1 (25) !standard G.1.2 (09) !class binding interpretation 96-04-04 !status Corrigendum 2000 99-07-20 !status WG9 Approved 97-11-14 !status ARG Approved (letter ballot: 11-0-0) 97-10-27 !status ARG Approved (subject to letter ballot) 97-04-11 !status work item 97-03-19 !status ARG Approved (subject to letter ballot) 8-0-2 96-10-07 !status work item 96-05-08 !status received 96-04-04 !reference AI95-00041 !priority High !difficulty Medium !qualifier Omission !subject Classification of Language-Defined Packages !summary The following language-defined packages are declared Pure: Ada.Numerics.Complex_Elementary_Functions G.1.2(9) Ada.Numerics.Complex_Types G.1.1(25) Ada.Numerics.Elementary_Functions A.5.1(9) The other nongeneric equivalents defined in these sections are also declared Pure, if they exist. The following language-defined package is a remote types package: Ada.Finalization 7.6(4) For each language-defined generic package that is declared Pure (or preelaborated), the private part must not contain anything that would prevent instances from being declared Pure (preelaborated, respectively). !question None of the language-defined packages has a pragma Remote_Types. This makes distributed programming less convenient, because the types declared in these packages cannot be transported across partitions (unless, of course, the package has a pragma Pure). Should some of the language-defined packages be remote types packages? !recommendation (See summary.) !wording Add "pragma Pure();" or "pragma Remote_Types();" to each of the listed packages. !discussion Ada.Numerics has three children that are instances of declared-pure generic packages. The intent is that these instances also be declared pure, even though 8652/0034 (AI-00041) says that this does not happen by default. Now, it might seem that many language-defined packages ought to be remote types packages. However, it turns out that this makes sense for very few language-defined packages, and is important for only one: Finalization. Detailed analysis follows. The following is a list of all the language-defined library units. On the right, "Pure" or "Preelaborate" are the pragmas shown in the RM for each package. (The three instances mentioned above are also shown as "Pure".) For each package, "Yes" means it could reasonably be a remote types package; "No" means it should not. If neither "Yes" nor "No" is shown, that means "No", and the reason is that the type(s) declared in that package are inappropriate for transporting across partitions. This is true of the I/O packages, for example -- we don't want to require transporting files across partitions. There is no point in making a declared-pure package into a remote types package, so all the ones marked "Pure" are "No" by default. It makes sense for a package to have both pragmas Preelaborate and Remote_Types. "No -- access type T" means, "We can't make it remote types, because it contains an access type, and we don't want that access type to be a remote access type." "No -- depends on X" means, "We can't make it remote types, because it depends on X, and we have decided X should not be pure, shared passive, or remote types." See E.2.2(6). Note that Ada.Calendar and Ada.Real_Time should not be remote types, because we wish to allow implementations to choose a different representation for the time-related types on different partitions. For example, type Calendar.Time on one partition might use a different "epoch" than on another partition. The types involved are: Calendar.Time, Real_Time.Time, Real_Time.Time_Span, and Real_Time.Seconds_Count. Thus, in order to pass time values across partitions, the programmer will have to define a application-specific time type, and translate to that. Note that Ada.Exceptions is listed as "No", because it contains an access type that should not be a remote access type. It was one of the cases mentioned in the comments that prompted this AI. This is unfortunate; one would like to transport values of types Exception_Id and Exception_Occurrence. Note that Ada.Task_Identification should not be remote types. If it were, then one could pass a Task_ID across partitions, and then do things like Abort_Task on that Task_ID on the "wrong" partition. This would require the tasking run-time system to know about distribution, which was never intended; alternatively, it would require us to declare such cases erroneous, which seems pointlessly error prone. Note also that this package cannot be declared Pure or Shared_Passive, because Task_ID is likely implemented as a pointer. Note that the Discrete_Random and Float_Random packages are not made remote types. It makes no sense to copy the generators, since they are supposed to have reference semantics. This leaves Finalization, Characters.Handling, Command_Line, and Interfaces.COBOL as potential candidates for being remote types packages. Of these, the only significant additional functionality is for Finalization. Therefore, we choose to make Finalization a remote types package, and leave the other three as specified in the RM. (It seems silly, for example, to make Command_Line remote types, so that Exit_Statuses can be transported, when Strings.Unbounded is not made remote types, so that Unbounded_Strings cannot be transported; the latter would be far more useful, if it were possible.) Analysis of each language-defined library unit follows: Standard A.1(4) Pure Ada A.2(2) Pure Ada.Asynchronous_Task_Control D.11(3) No -- no need to make it remote types. Ada.Calendar 9.6(10) Ada.Characters A.3.1(2) Pure Ada.Characters.Handling A.3.2(2) Preelaborate Yes. Ada.Characters.Latin_1 A.3.3(3) Pure Ada.Command_Line A.15(3) Preelaborate Yes. Ada.Decimal F.2(2) Pure Ada.Direct_IO A.8.4(2), A.9(3) Ada.Dynamic_Priorities D.5(3) No -- no need to make it remote types. Ada.Exceptions 11.4.1(2) No -- access type Exception_Occurrence_Access. Ada.Finalization 7.6(4) Preelaborate Yes. Ada.Float_Text_IO A.10.9(32) Ada.Float_Wide_Text_IO A.11(3) Ada.Integer_Text_IO A.10.8(20) Ada.Integer_Wide_Text_IO A.11(3) Ada.Interrupts C.3.2(2) No -- access type Parameterless_Handler. Ada.Interrupts.Names C.3.2(12) No -- depends on Ada.Interrupts. Ada.IO_Exceptions A.13(3) Pure Ada.Numerics A.5(3) Pure Ada.Numerics.Complex_Elementary_Functions G.1.2(9) Pure Ada.Numerics.Complex_Types G.1.1(25) Pure Ada.Numerics.Discrete_Random A.5.2(17) No -- the generator parameter is supposed to have reference semantics. Ada.Numerics.Elementary_Functions A.5.1(9) Pure Ada.Numerics.Float_Random A.5.2(5) No -- the generator parameter is supposed to have reference semantics. Ada.Numerics.Generic_Complex_Elementary_Functions G.1.2(2) Pure Ada.Numerics.Generic_Complex_Types G.1.1(2) Pure Ada.Numerics.Generic_Elementary_Functions A.5.1(3) Pure Ada.Real_Time D.8(3) Ada.Sequential_IO A.8.1(2) Ada.Storage_IO A.9(3) Preelaborate No -- depends on System. Ada.Streams 13.13.1(2) Pure Ada.Streams.Stream_IO A.12.1(3) Ada.Strings A.4.1(3) Pure Ada.Strings.Bounded A.4.4(3) Preelaborate No -- depends on Ada.Strings.Maps. This means Bounded_Strings cannot be transported. Ada.Strings.Fixed A.4.3(5) Preelaborate No -- depends on Ada.Strings.Maps. This means the functions in this package cannot be called from the spec of a remote types package. Ada.Strings.Maps A.4.2(3) Preelaborate No -- access type Character_Mapping_Function. Ada.Strings.Maps.Constants A.4.6(3) No -- depends on Ada.Strings.Maps. Ada.Strings.Unbounded A.4.5(3) No -- access type String_Access; depends on Ada.Strings.Maps. This means Unbounded_Strings cannot easily passed across partitions. Ada.Strings.Wide_Bounded A.4.7(1) No -- depends on Ada.Strings.Wide_Maps. Ada.Strings.Wide_Fixed A.4.7(1) No -- depends on Ada.Strings.Wide_Maps. Ada.Strings.Wide_Maps A.4.7(3) No -- access type Character_Mapping_Function. Ada.Strings.Wide_Maps.Wide_Constants A.4.7(1) No -- depends on Ada.Strings.Wide_Maps. Ada.Strings.Wide_Unbounded A.4.7(1) No -- access type String_Access. Ada.Synchronous_Task_Control D.10(3) No -- no need to make it remote types. Ada.Tags 3.9(6) No -- if type Tag needs to be transported, one can use the External_Tag function. Ada.Task_Attributes C.7.2(2) No -- access type Attribute_Handle. Ada.Task_Identification C.7.1(2) Ada.Text_IO A.10.1(2) Ada.Text_IO.Complex_IO G.1.3(3) Ada.Text_IO.Editing F.3.3(3) Ada.Text_IO.Text_Streams A.12.2(3) Ada.Unchecked_Conversion 13.9(3) Pure Ada.Unchecked_Deallocation 13.11.2(3) Preelaborate No -- a procedure cannot be remote types, by AI-00048. Ada.Wide_Text_IO A.11(2) Ada.Wide_Text_IO.Complex_IO G.1.4(1) Ada.Wide_Text_IO.Editing F.3.4(1) Ada.Wide_Text_IO.Text_Streams A.12.3(3) Interfaces B.2(3) Pure Interfaces.C B.3(4) Pure Interfaces.C.Pointers B.3.2(4) Preelaborate No -- access type Pointer. Interfaces.C.Strings B.3.1(3) Preelaborate No -- access type char_array_access. Interfaces.COBOL B.4(7) Preelaborate Yes. Interfaces.Fortran B.5(4) Pure System 13.7(3) Preelaborate No -- transportation of type Address makes no sense. However, note that an implementation is allowed to add pragma Remote_Types if it wants to. System.Address_To_Access_Conversions 13.7.2(2) Preelaborate No -- access type Object_Pointer. System.Machine_Code 13.8(7) Don't care -- entire contents are implementation defined, so we don't need to say anything about this one. System.RPC E.5(3) No -- RPC is used in the implementation of inter-partition communication, so it doesn't make sense to make it remote types. System.Storage_Elements 13.7.1(2) Preelaborate No -- depends on System. It might make sense to transport values of types, Storage_Element, Storage_Array, etc, though. Hmm. System.Storage_Pools 13.11(5) Preelaborate No -- depends on System. !corrigendum 7.06(4) @drepl @xcode<@b Ada.Finalization @b @b Preelaborate(Finalization);> @dby @xcode<@b Ada.Finalization @b @b Preelaborate(Finalization); @b Remote_Types(Finalization);> !corrigendum A.5.1(9) @drepl The library package Numerics.Elementary_Functions defines the same subprograms as Numerics.Generic_Elementary_Functions, except that the predefined type Float is systematically substituted for Float_Type'Base throughout. Nongeneric equivalents of Numerics.Generic_Elementary_Functions for each of the other predefined floating point types are defined similarly, with the names Numerics.Short_Elementary_Functions, Numerics.Long_Elementary_Functions, etc. @dby The library package Numerics.Elementary_Functions is declared pure and defines the same subprograms as Numerics.Generic_Elementary_Functions, except that the predefined type Float is systematically substituted for Float_Type'Base throughout. Nongeneric equivalents of Numerics.Generic_Elementary_Functions for each of the other predefined floating point types are defined similarly, with the names Numerics.Short_Elementary_Functions, Numerics.Long_Elementary_Functions, etc. !corrigendum G.1.1(25) @drepl The library package Numerics.Complex_Types defines the same types, constants, and subprograms as Numerics.Generic_Complex_Types, except that the predefined type Float is systematically substituted for Real'Base throughout. Nongeneric equivalents of Numerics.Generic_Complex_Types for each of the other predefined floating point types are defined similarly, with the names Numerics.Short_Complex_Types, Numerics.Long_Complex_Types, etc. @dby The library package Numerics.Complex_Types is declared pure and defines the same types, constants, and subprograms as Numerics.Generic_Complex_Types, except that the predefined type Float is systematically substituted for Real'Base throughout. Nongeneric equivalents of Numerics.Generic_Complex_Types for each of the other predefined floating point types are defined similarly, with the names Numerics.Short_Complex_Types, Numerics.Long_Complex_Types, etc. !corrigendum G.1.2(9) @drepl The library package Numerics.Complex_Elementary_Functions defines the same subprograms as Numerics.Generic_Complex_Elementary_Functions, except that the predefined type Float is systematically substituted for Real'Base, and the Complex and Imaginary types exported by Numerics.Complex_Types are systematically substituted for Complex and Imaginary, throughout. Nongeneric equivalents of Numerics.Generic_Complex_Elementary_Functions corresponding to each of the other predefined floating point types are defined similarly, with the names Numerics.Short_Complex_Elementary_Functions, Numerics.Long_Complex_Elementary_Functions, etc. @dby The library package Numerics.Complex_Elementary_Functions is declared pure and defines the same subprograms as Numerics.Generic_Complex_Elementary_Functions, except that the predefined type Float is systematically substituted for Real'Base, and the Complex and Imaginary types exported by Numerics.Complex_Types are systematically substituted for Complex and Imaginary, throughout. Nongeneric equivalents of Numerics.Generic_Complex_Elementary_Functions corresponding to each of the other predefined floating point types are defined similarly, with the names Numerics.Short_Complex_Elementary_Functions, Numerics.Long_Complex_Elementary_Functions, etc. !ACATS test Create C-Tests to check each package changed (for the core and annex G): Try withing the units Ada.Numerics.Elementary_Functions (core), Ada.Numerics.Complex_Elementary_Functions (annex G), Ada.Numerics.Complex_Types (annex G) into a Pure package. Insure that the various generic units can be instantiated, (with a Pragma Pure given), and withed into a Pure package. Create a C-Test for annex E to verify that Ada.Finalization is a Remote_Types package, by withing it into a Remote_Types package. !appendix !section E.2.2(08) !subject Wording of one Remote_Types restriction !reference RM95-E.2.2(8) !from Laurent Guerby 1996-03-07 !keywords distribution, restriction, wording !reference 96-5435.a Laurent Guerby 96-3-7>> !discussion [Summary of a discussion between me and some of the GNAT Team members (Ada Core Technologies)] I think that the wording of the restriction RM95-E.2.2(8) is a bit clumsy (as far as I fully understand it and its intent ;-) : "* if the full view of a type declared in the visible part of the library unit has a part is of a non-remote access type, then that access type, or the type of some part that includes the access type subcomponent, shall have user-specified Read and Write attributes." It does not catch the following case : type T is private private type T is access integer; -- allowed without user specified Read or Write attributes, -- excepted if the meaning of "part" includes the full definition -- of the type (but RM95-3.2(6) seems not to cover it). Also, it restricts (indeed not that much ;-) the freedom of the Ada programmer in the following case : type T is private private type A is access Integer; type T is record X : A; -- other components end T; -- You have to specifie Read and Write for type type A, -- specifying them for the type T is not enough -- (of course you can specify both of them to achieve your goals) Ed Shonberg (ACT) writes : I think this is what might be called an "unfriendly" reading of the : RM. I agree that "part" is used loosely here, but I'm sure that this : includes the type itself, and that this is intended to be : illegal. Otherwise the whole purpose of the check would be defeated. Of course but two "or the type itself" inserted in the clause would make it completely clear, for the reader and for the compiler writer. It can also be checked by ACVC tests. -- -- Laurent Guerby, student at Telecom Bretagne (France), Team Ada -- "Use the Source, Luke. The Source will be with you, always (GPL)" -- http://www-eleves.enst-bretagne.fr/~guerby/ (GATO Project) -- Try GNAT, the GNU Ada 95 compiler (ftp://cs.nyu.edu/pub/gnat) **************************************************************** !section 11.4.1(16) !subject Categorization of Ada.Exceptions (and others) as Remote_Types !reference RM95-11.4.1(16) !from Laurent Guerby 1996-03-07 !keywords categorization, exceptions, predefined units !reference 96-5436.a Laurent Guerby 96-3-7>> !discussion [Summary of a discussion between GNAT Team members, Tucker Taft and me, may be Tucker has already sent such a comment] I wrote in comp.lang.ada : I was just thinking about writing a Comment Submission. There's : plenty of predefined package that can be Remote_Types. The most : surprising one is Ada.Exceptions where RM95 11.4.1(16) (and AARM : 16.a-c) takes care of distribution, and where the omission of : Remote_Types looks like a goof. The pragma Preelaborate has been : over-used, a few Remote_Types (or implementation requirements) will : make the Ada distributed programmers happy ;-). A review of the categorization of the language predefined libraries looks like a good idea to me. Tucker Taft answered in comp.lang.ada : Sounds like we should put a pragma Remote_Types wherever possible. -- -- Laurent Guerby, student at Telecom Bretagne (France), Team Ada -- "Use the Source, Luke. The Source will be with you, always (GPL)" -- http://www-eleves.enst-bretagne.fr/~guerby/ (GATO Project) -- Try GNAT, the GNU Ada 95 compiler (ftp://cs.nyu.edu/pub/gnat) **************************************************************** !section E.2(00) !subject Finalization and Remote_Types !reference RM95-E.2 RM95-7.6 !from Laurent Guerby 1996-03-07 !keywords finalization, distribution, memory leaks !reference 96-5437.a Laurent Guerby 96-3-7>> !discussion [More complete point of view on the Ada.Finalization categorization subject] On a typical distributed application, the Ada programmer will define a few non trivial types involving dynamically allocated structures (lists, trees). Since the unit Ada.Finalization is not categorized as Remote_Types, the programmer cannot use this facilitie to provide automatic storage reclamation, and have to provide explicit finalizatiuon routines (of course if the pragma Controlled is supported by the implementation in conjunction with the distributed annex that's fine ...). Of course storage management is a critical point for long-running application (even for small ones, like our Distributed Ada Ray Tracer, DART ;-). As far as I understand it, controlled types are typically managed using a "finalization chain", involving two pointers in each object. Since marshalling and unmarshalling involve only constrained objects (the attributes used are Read and Write, not Input and Output), I think that supporting interpartition exchange of controlled can be "easily" supported in a simple way, by avoiding the transmission of these two pointers since the local object on the receiver side will have them already set (ok, I'm not an expert on the subject ;-). To summarize my position, the annex E users may want to offer automatic storage reclamation (using the well-defined Ada 95 capabilities on the subject, without using Unchecked_Conversion or letting dangling references) and hope that it's not too much trouble for the Ada compiler writer. This request has to be read in the context of a re-categorization of the predefined units (see previous request) using Remote_Types wherever possible (Ada.Strings.Unbounded comes to mind). -- -- Laurent Guerby, student at Telecom Bretagne (France), Team Ada -- "Use the Source, Luke. The Source will be with you, always (GPL)" -- http://www-eleves.enst-bretagne.fr/~guerby/ (GATO Project) -- Try GNAT, the GNU Ada 95 compiler (ftp://cs.nyu.edu/pub/gnat) **************************************************************** !section E.2.2(08) !subject Wording of one Remote_Types restriction !reference RM95-E.2.2(8) !from Laurent Guerby 1996-03-07 !keywords distribution, restriction, wording !reference 96-5435.a Laurent Guerby 96-3-7 !reference 96-5438.a Pascal Leroy 96-3-8>> !discussion > I think that the wording of the restriction RM95-E.2.2(8) is a bit > clumsy (as far as I fully understand it and its intent ;-) : > > "* if the full view of a type declared in the visible part of the > library unit has a part is of a non-remote access type, then that > access type, or the type of some part that includes the access type > subcomponent, shall have user-specified Read and Write attributes." > > It does not catch the following case : > > type T is private > private > type T is access integer; > -- allowed without user specified Read or Write attributes, > -- excepted if the meaning of "part" includes the full definition > -- of the type (but RM95-3.2(6) seems not to cover it). If you had lookep up "part" in the index, you would have noticed that this word is defined in RM95 3.2(6): "a part of an object or value is used to mean the whole object or value, or any set of its subcomponents." So obviously, Read and Write are required for T. > type T is private > private > type A is access Integer; > type T is record > X : A; > -- other components > end T; > > -- You have to specifie Read and Write for type type A, > -- specifying them for the type T is not enough > -- (of course you can specify both of them to achieve your goals) I cannot see how you deduce this statement from the RM. If you define Read and Write for type T, then "the type of some part that includes the access type subcomponent" has the required attributes (RM95 E.2.2(8)). Again, this probably boils down to the definition of "part." > Ed Shonberg (ACT) writes > > : I think this is what might be called an "unfriendly" reading of the > : RM. I agree that "part" is used loosely here, but I'm sure that this > : includes the type itself, and that this is intended to be > : illegal. Otherwise the whole purpose of the check would be defeated. I concur (except that part is not used "loosely." > Of course but two "or the type itself" inserted in the clause would > make it completely clear, for the reader and for the compiler > writer. It can also be checked by ACVC tests. The RM is correct in its definition and usage of the word "part," and adding redundancy everywhere wouldn't make it easier to understand. Pascal _____________________________________________________________________ Pascal Leroy +33.1.30.12.09.68 pleroy@rational.com +33.1.30.12.09.66 FAX **************************************************************** !section E.2.2(08) !subject Wording of one Remote_Types restriction !reference RM95-E.2.2(8) !reference 96-5435.a Laurent Guerby 1996-03-07 !keywords distribution, restriction, wording !from Tucker taft 96-03-08 !reference 96-5442.a Tucker Taft 96-3-8>> !discussion > [Summary of a discussion between me and some of the GNAT Team members > (Ada Core Technologies)] > > I think that the wording of the restriction RM95-E.2.2(8) is a bit > clumsy (as far as I fully understand it and its intent ;-) : > > "* if the full view of a type declared in the visible part of the > library unit has a part is of a non-remote access type, then that > access type, or the type of some part that includes the access type > subcomponent, shall have user-specified Read and Write attributes." To understand this rule, you have to know that a "part" of an object is defined to include the object itself. See RM95 3.2(6). The RM relies on this definition in several places to keep rules simpler. > ... > Of course but two "or the type itself" inserted in the clause would > make it completely clear, for the reader and for the compiler > writer. It can also be checked by ACVC tests. This wouldn't be the only rule where we would have to add "or the type/object/value itself". There are several rules where you need a term like "part" which is defined to include the whole object. > -- Laurent Guerby, student at Telecom Bretagne (France), Team Ada > -- http://www-eleves.enst-bretagne.fr/~guerby/ (GATO Project) -Tuck **************************************************************** !section E.2.2(08) !subject Pragma Remote_Types vs. packages Calendar and Real_Time !reference AI-00126 !reference RM95-E.2.2(08) !referenece RM95-9.6 !reference RM96-D.8 !from Offer Pazy 96-04-30 !reference 96-5529.a Offer Pazy 96-4-30>> !discussion The draft version of AI95-00126/00 says that packages Calendar and Real_Time should be defined to be Remote_Types packages. This means that Time values can be passed across the network. However, this goes against the original intent, which was clearly to leave the issue of a "common time notion" in a distributed ADa program outside the scope of the LRM. (In fact, during the revision, package Calendar, was used as the typical example for a "normal" package). The proposed change will several problems: The RM does not require clocks to be synchronized between two different partitions, and in fact clock values are often *not* synchronized. It also does not require that time-zone and DST treatment be the same for all partitions (in the case of Calendar.Time), nor does it imply that the epoch and accuracy of Real-TIme.Time should be the same even for homogeneous systems. In general, the approach was that time values on one partition, do not necessarily mean much on another. Therefore, if one partition sends a message containing a Time value to another partition, then that Time value will not necessarily have any relationship to the current time on the receiving partition (and the receiving partition must better not attempt to perform a Split on a Time value received from another partition). Ada 95 (intentionally) does not provide for clock synchronization and it is left up to the user or the implementation-defined RTS/PCS (there is no Set_Clock facility). If such a functionality is needed, it will be provided together with its semantics and appropriate types. Probably deltas of time values should be used with agreed-upon meaning and for this the language provide enough mechanisms. (Note that the Time type are private and so is Real_Time.Time_Span and the same argument should be applied to the latter as well.) As an aside, *one* of the reasons for not providing cross-partition rendezvous in the language (and in particular, timed entry calls) was precisely this issue of a lack of a common time notion. Furthermore, making these packages Remote_Types implies that both partitions have to use the same representation for the Time types. For example, suppose one partition represents Time as a 64-bit counter, which is the number of milliseconds since 4:00 PM on March 7, 1959. But another partition uses 128 bits, counts time in microseconds, and counts time values since some other starting point. If a time value is sent from one partition to another, the bits being sent will make no sense on the receiving partition. Finally, the RM clearly does not define these packages as Remote_Types, so if there's any doubt as to whether such a definition would place additional implementation constraints or cause other problems, the decision should be to leave things as they are. Unlike the other packages mentioned in AI, these two packages were not simply overlooked. In any case, if the programmer wishes to pass Time values across partitions, the programmer ought to define an agreed-upon representation, and explicitly convert to that representation. To summarize, my view is that such a conceptual change is quite significant at this point and is a big departure from the Ada95 distribution approach. Yes, in some straight-forward instances, allowing time values to be communicated, would make things simpler for the user, but I am worried that providing this in the general case, would lead users to believe that more is expected from the RTS/PCS, and that the partitions are required to be more coupled than they really are. The trade-off in this case should be, in my view, to leave things as they are, that is, explicitly admitting that communicatble time (note, "time" vs "Time") values is a user task and not a RTS/PCS task. Offer Pazy 972-3-648-5719 pazy@world.std.com **************************************************************** !section E.2.2(08) !subject Pragma Remote_Types vs. packages Calendar and Real_Time !reference AI-00126 !reference RM95-E.2.2(08) !referenece RM95-9.6 !reference RM96-D.8 !reference96-5529.a Offer Pazy 96-4-30 !from Ted Baker 96-05-01 !reference 96-5533.a Ted Baker 96-5-1>> !discussion I agree with Offer Pazy, that we intentionally avoided any requirement for distributed clock synchronization, or even agreement on time zones, and that it would be a grave mistake for the language to add such requirement on implementations. Besides ther good reasons given by Offer, I'd like to point out that there in an inherent trade-off between clock synchronization and local clock precision; For example, we could agree that the type Time is implemented as a 64-bit count of time quanta, and even agree on the value of the quantum (say 1 nanosecond), but then can we hope to keep two geographically separated clocks synchronized within one nanosecond? **************************************************************** !section 9.6(00) !subject Pragma Remote_Types vs. packages Calendar and Real_Time !reference AI-00126 !reference RM95-E.2.2(08) !referenece RM95-9.6 !reference RM96-D.8 !reference 96-5529.a Offer Pazy 96-4-30 !reference 96-5533.a Ted Baker 96-5-1 !reference 96-5534.a Robert A Duff 96-5-2>> !discussion > I agree with Offer Pazy, that we intentionally avoided any > requirement for distributed clock synchronization, or even > agreement on time zones, and that it would be a grave mistake for > the language to add such requirement on implementations. I agree. Just to clarify, though: the draft AI, which I wrote, does *not* propose to add such a requirement. It proposes that values of type Time can be passed from one partition to another. I have two questions: 1. Given that clocks are not required, by Ada, to be synchronized, does this imply that one should not be allowed to pass Time values across partitions? I don't really see why not. 2. Did we, and do we, wish to allow implementations to use different *representations* of Time on different partitions? If so, then clearly we cannot allow passing Time values across partitions. IMHO, these are two separate issues (clock synchronization, and representation of Time). It is conceivable that one would have a common *representation* of Time, without having any clock synchronization. When I'm talking on the telephone with somebody in India, the statement, "It's half-past ten, here," is easily understood, even though our clocks are set to different values, and I don't remember how many time zones there are between here and there. And even though I don't know how fanatical the other person is about keeping clocks "correct", and even though it takes some amount of time for the message to travel. (In fact, I can use this information to *calculate* how many time zones there are between here and there, given that I have my own clock.) If we're not sure about this, we probably ought to be conservative -- i.e., leave Calendar and Real_Time as in the RM. - Bob P.S. Note that if you look at the top of this e-mail (when you receive it tomorrow), you will see a time value, which will tell you when I sent it. This works because we agree on what that (string) *representation* of time means, not because your computer and my computer have synchronized their clocks. ;-) **************************************************************** !section E.2.2(08) !subject Pragma Remote_Types vs. packages Calendar and Real_Time !reference AI-00126 !reference RM95-E.2.2(08) !referenece RM95-9.6 !reference RM96-D.8 !reference 96-5529.a Offer Pazy 96-4-30 !reference 96-5533.a Ted Baker 96-5-1 !from Ted Baker 96-5-2 !reference 96-5535.a Ted Baker 96-5-2>> !discussion | I agree. Just to clarify, though: the draft AI, which I wrote, does | *not* propose to add such a requirement. It proposes that values of | type Time can be passed from one partition to another. I have two | questions: | 1. Given that clocks are not required, by Ada, to be synchronized, does | this imply that one should not be allowed to pass Time values across | partitions? I don't really see why not. Yes. As I said in the part of my message that you did not quote, we could certainly agree that time (for example) is represented as a 64-bit count of ticks. The issue is whether such a requirement buys us anything if the time values cannot be compared meaningfully. To compare values, we would further need to agree on the meaning of one "tick", say one nanosecond, and the logical "epoch" or starting time of the clock. Then, we could compare time values from different systems, and talk about user-level clock synchronization protocols. However, this is a big assumption already. If we have heterogeneous processors, the local tick sizes may differ, as may the local clock start times. I don't think we want to require agreement on those. | 2. Did we, and do we, wish to allow implementations to use different | *representations* of Time on different partitions? If so, then clearly | we cannot allow passing Time values across partitions. Do you consider the logical value of one tick, and the logical start time of the clock to be differences in "representation"? If so, then we do want to allow different representations. If you just mean the number of bits, then maybe we could agree that time is (say) a signed 64-bit integer, and allow sharing of values across partitions. That still leaves the question of whether this is a good thing for users. Maybe, for an informed user, it could be useful. On the other hand, it would need to be labeled as an "unsafe programming" feature, since the potential for foot-shooting is very great. --Ted Baker **************************************************************** !section E.2.2(08) !subject Pragma Remote_Types vs. packages Calendar and Real_Time !reference AI-00126 !reference RM95-E.2.2(08) !referenece RM95-9.6 !reference RM96-D.8 !reference 96-5529.a Offer Pazy 96-4-30 !reference 96-5533.a Ted Baker 96-5-1 !reference 96-5535.a Ted Baker 96-5-2 !from Bob Duff !reference 96-5536.a Robert A Duff 96-5-2>> !discussion > Do you consider the logical value of one tick, and the > logical start time of the clock to be differences in "representation"? Yes. These things are independent of the current Clock value. If I say to you, it's ten o'clock on May 2, 1996, we both agree on what that means. The epoch is the birth of Christ, or actually, what some third-century Roman thought the birth of Christ was. Your clock is different, so you know I really mean, "Bob's clock says it's ...", but we agree on what that measure of time means. For example, the statement "Please set your watch to 11:30" makes sense to you, no matter what your watch currently shows. > If so, then we do want to allow different representations. OK. That answers my second question. And if true, my first question is irrelevant. > If you just mean the number of bits, then maybe we could agree > that time is (say) a signed 64-bit integer, and allow sharing of > values across partitions. No, I don't just mean the number of bits. I include the interpretation of those bits. For example, one implementation might use two's complement, and another implementation might use who-knows-what. And the size of one tick, and the epoch, can be different. Another implementation might use a record containing counts of year, month, day, seconds, hundredths-of-seconds, etc. To me, all these things constitute different representations of time, whereas different clock settings do not. You're saying that these things can be different on different partitions. If so, then I agree, we don't want to make Calendar into a Remote_Types package. > That still leaves the question of whether this is a good thing for > users. Maybe, for an informed user, it could be useful. On the > other hand, it would need to be labeled as an "unsafe programming" > feature, since the potential for foot-shooting is very great. Well, the notion of measuring time allows a lot of foot-shooting anyway, I think. ;-) - Bob **************************************************************** !section E.2.2(08) !subject Pragma Remote_Types vs. packages Calendar and Real_Time !reference AI-00126 !reference RM95-E.2.2(08) !reference RM95-9.6 !reference RM96-D.8 !reference 96-5529.a Offer Pazy 96-4-30 !reference 96-5533.a Ted Baker 96-5-1 !reference 96-5535.a Ted Baker 96-5-2 !reference 96-5536.a Robert A Duff 96-5-2 !reference 96-5538.a Ted Baker 96-5-4 !reference Bob Duff 96-5-4 !from Offer Pazy 96-5-4 !reference 96-5540.a Offer Pazy 96-5-4>> !discussion I think it will be a mistake to confuse the issue of time with the general issue of representation and heterogeneity. I think that we all agree that Ada 95 and the Annex E do not attempt to support heterogeneous systems. We do assume that Integer/floats, etc. are represted the same and there is no attempt to support conversions. Note also that these two types are not private which I think it is an important factor. The two Time types are private. Yes, we are expecting communicating APs to use the same representations (e.g. 64 bits). But, based on past experience, many other aspects of the Time types are likely to be configurable (even by the user) to accomodate different trade-offs. The starting point and accuracy are two of the likely properties to be changed from one AP to the other even for an otherwise homogeneous system!. And the question is do we want the standard Annex E implementation to either disallow such configurability or to support standard notion or convesions. I think the answer is clearly "no". Either the user or an implementation extention will provide some conversion routines from the hidden type Time to something hat will be meaningfull across APs. And we clearly (I think) don't want this stardard represntation to necessarily be the internal one. One may still may have a different internal represnetation, and use the default 'read/'Write attributes to do the right conversions, but where is this standard definition to convert to? Offer Pazy 972-3-648-5719 pazy@world.std.com **************************************************************** !section E.2.2(08) !subject Classification pragmas for predefined packages !reference AI95-00126 !from Erhard Ploedereder !reference 96-5587.a Erhard Ploedereder 96-5-31>> !discussion AI-129 should be extended to encompass all classification pragmas for all predefined packages. For example, which of these packages, if not pure, are categorized as shared-passive ? Particularly, many of the packages on Annexes C-G lack such pragmas. At a minimum, confirm that the RM categorizations of all these packages is as intended. Note the interaction with AI-41 in the case of generic packages. **************************************************************** !section E.2.2(08) !subject Classification of Language-Defined Packages !reference AI95-00126 !from Pascal Leroy 96-11-29 !reference 96-5776.a Pascal Leroy 96-11-29>> !discussion Two comments on AI95-00126: 1 - The !summary states that the (pseudo-)instantiations corresponding to Float (Ada.Numerics.Complex_Elementary_Functions, Ada.Numerics.Complex_Types, and Ada.Numerics.Elementary_Functions) are pure. It should also state that the (pseudo-)instantiations corresponding to other predefined floating point types (Ada.Numerics.Long_Elementary_Functions and the like) are pure if they exist. 2 - While a number of generic units are classified as pure or preelaborated, the language doesn't say a word about their instantiations. So it seems that an implementation is entitled to write Generic_Elementary_Functions as follows: with Some_Pure_Function_Returning_Integer; generic type Float_Type is digits <>; package Ada.Numerics.Generic_Elementary_Functions is pragma Pure (Ada.Numerics.Generic_Elementary_Functions); ... private subtype S is Integer range 1 .. Some_Pure_Function_Returning_Integer; end; But of course, this prevents any instantiation of Generic_Elementary_Functions in a pure or preelaborated unit. This is a portability issue, because different implementations may put vastly different declarations in the private parts of the predefined generic packages. Note that this problem only exists because AI95-00041 has decided that the categorization pragmas do not apply to instantiations. Pascal _____________________________________________________________________ Pascal Leroy +33.1.30.12.09.68 pleroy@rational.com +33.1.30.12.09.66 FAX ****************************************************************