!standard E.2 (13) 99-08-31 AI95-00208/05 !class binding interpretation 98-10-10 !status Corrigendum 2000 99-07-27 !status WG9 approved 99-06-12 !status ARG approved (with changes) 9-0-0 99-03-26 !status work item 98-10-13 !status received 98-10-01 !priority Medium !difficulty Hard !qualifier Error !subject What is the meaning of "same representation" in all partitions? !summary Paragraph E.2(13) requires the "same representation" in all partitions. This requirement prevents heterogeneous distributed systems, and is not needed, so it is deleted. !question E.2(13) says: "Implementation Requirements: For a given library-level type declared in a preelaborated library unit or in the declaration of a remote types or remote call interface library unit, the implementation shall choose the same representation for the type upon each elaboration of the type's declaration for different partitions of the same program." This seems overly restrictive. It means that Ada 95 supports heterogeneous distributed systems only if the implementation manages to use the same representation for a type on all nodes. Is this intended? (No.) !recommendation (See summary.) !wording Delete E.2(13) in its entirety. !discussion The requirement for the same representation for types in shareable library packages is over-specification. What is required is that the types have similar semantics and have consistent values when remotely accessed. While requiring the same representation insures that the requirement is met, it prevents many possible heterogeneous systems. For instance, the byte order of integer types may be different on different processors, but this has no effect on the semantics of the types. If an implementation uses a representation independent format for its communication between partitions, heterogeneous distributed systems on processors with differing numeric formats can be supported. (Note that the storage element stream for a scalar type is implementation-defined.) Such an implementation could correctly support all of the semantics of Annex E. Such heterogeneous systems have been used in avionics to insure that answers calculated are independent of implementation and processor errors. This is done by calculating answers on several different processors (each with its own executable code), and comparing them. Ada should support the construction of such systems with each processor running one or more active partitions. Furthermore, there seems to be no reason to require the rule even for homogeneous systems. The rule essentially says that the easiest implementation is required. If an Ada implementation has a reason to go through the extra work to support multiple representations, there seems to be no reason for the standard to get in its way. If an implementation does support different representations in different active partitions, we believe it is best to leave the exact semantics to the implementation. We expect that implementations will do what is necessary to insure that the semantics of types with different representations is similar and meaningful in each partition. Therefore, the rule requiring the same representation in each partition is not needed, and is deleted. !corrigendum E.02(13) @ddel For a given library-level type declared in a preelaborated library unit or in the declaration of a remote types or remote call interface library unit, the implementation shall choose the same representation for the type upon each elaboration of the type's declaration for different partitions of the same program. !ACATS test The representations of items in different partitions is not testable. !appendix !topic Ada 95 and Heterogeneous Distributed Systems !reference RM95-E(6), RM-95-E.2(13) !from Thomas Wolf 1998-08-06 <> !discussion Why does the RM require same representations of types used in remote communications? After all, the RM also allows execution of a distributed Ada 95 application on a heterogeneous distributed system, for E(6) states: "Implementation Permissions: An implementation may require that the set of processing nodes of a distributed system be homogeneous." This implies clearly that the annex itself is open enough to allow execution of an application in a heterogeneous distributed system. Otherwise, this implementation permission would be superfluous, and instead there should be a requirement somewhere that only homogeneous nodes may be used. However, E.2(13) says: "Implementation Requirements: For a given library-level type declared in a preelaborated library unit or in the declaration of a remote types or remote call interface library unit, the implementation shall choose the same representation for the type upon each elaboration of the type's declaration for different partitions of the same program." First, is it intentional that an implementation has to choose identical representations even for units mentioned in a pragma Preelaborate (which is not a categorization pragma as far as distribution is concerned)? Wouldn't it be better to spell out that types declared in pure or shared passive library units are meant? Second, E.2(13) seems overly restrictive to me. It means that Ada 95 supports heterogeneous distributed systems only if the implementation manages to use the same representation for a type on all nodes. What exactly is the meaning of "representation" here? If it means "external, marshaled representation", then the paragraph is ok, but this interpretation of "representation" in this context should be clearly mentioned in the RM. If it means "bit-by-bit identity" (and I think this is the case), then the requirement is too strong: it would even take endian-ness into account, but that has no effect on the semantics of the type! I think it would be sufficient to require only that an implementation use the same *declarations* for all types in package Standard or in any of the other standard library units that are declared pure. This makes sure that all aspects left "implementation-defined" in the standard library are identical on all partitions in the distributed application. If an implementation *can* actually provide equal representations on all platforms in a heterogeneous distributed system, fine, then it can save some conversion overhead; but if it can't, it still has the freedom to insert conversions between representations as needed. What was the reason for the requirement in E.2(13)? I can only speculate, as neither the RM, nor the Rationale, nor the Annotated RM give any hints. I don't see any compelling reason for it. In what follows, I try to show that the much weaker requirement of equal type definitions for standard types is sufficient and considerably widens the applicability of Ada 95 to heterogenous distributed systems. Some possible rationales for E.2(13) I could come up with: (1) Standard is a pure package, and we want the standard types to have the same representation. I don't think this is necessary. What I'd really want in a hetero- geneous system is that the standard types have the same definition, i.e., the same *ranges and precisions*. If that is given, their semantics will be the same even on different platforms! What bit patterns, alignments, and so on are used on different platforms is immaterial as long as the stream atrtributes ('Read, 'Write, 'Input, 'Output) on all platforms in the heterogeneous distributed system agree on a machine-independent encoding. Such encodings exist, and even though they may not be standardized by an ISO standard, an implementation can use them for marshaling/unmarshaling. (2) If a user declares a type in a pure package for instance, we want to be able to use that type in remote communications (as a formal parameter type of a remotely callable subprogram, perhaps), so representations must be identical. Not true in my opinion. The semantics of a type is defined by its declaration, not by its representation. If I declare a type type My_Integer is range -Something .. +Something; I don't care about its representation as far as remote communication is concerned. Again, all that is needed is that the stream attributes for the type agree on a common marshaled format, from which they can reproduce the value at both ends of the line. It would therefore be sufficient to require only that the types have identical definitions (ranges/precisions). This is trivially true for any application-defined type, as the same source is used. Therefore, the requirement that all standard types have the same definition on all partitions would be good enough. (3) Identical representations are needed because of shared passive packages because several active partitions may exchange data through a shared passive package. I don't think this needs identical representations. There are two case to consider: (a) Shared passive packages implemented using true, hardware- shared memory. In this case, I think all partitions that will ever access the shared passive package will execute on homo- geneous nodes. Or is there any real system where heterogeneous nodes have access to a true, hardware-shared memory? I don't know of any. If there isn't any, there's no need to *require* "same representations": this will be always true anyway. Even if such a shared memory system existed, it would be sufficient to require that an implementation choose the same representation for types used in a shared passive library unit on all partitions that access that shared passive library unit. There's no need to require this for all partitions, nor is it necessary to require it for all types in active partitions, nor is it necessary to require it for types declared in remote types or remote call interfacelibrary units. (b) Shared passive packages implemented using a (distributed) shared memory system, i.e., software that makes the memory appear shared. In this case, accesses to the shared passive partition can easily be translated by the compiler to include marshaling upon writing and unmarshaling upon reading. The stream attributes can perform any necessary conversions of representations provided that types have the same definitions (range/precision) on all partitions involved. (4) Identical representations are needed for remote access values. Again, I do not agree. For these types, there always happens marshaling/unmarshaling, where any necessary conversions can be done. (This, by the way, is true for any library-level type declared in the specifications of remote types or remote call interface units. Requiring identical representations for types in RT or RCI units seems to me as overspecification even regardless of shared passive packages.) The absence of a standard for a machine-indepen- dent encoding doesn't matter. Such encodings exist, and an imple- mentation can use them. Remote access types and remote dispatching can be implemented even if remote types have different representations on different partitions. I'll try to illustrate this with the following example: consider three partitions A, B, and C. B gets a remote access to some object on A (necessarily by invoking a remotely callable subprogram on A) and later passes this remote access value on to C. C then makes a remote dispatching call on this remote access value. A uses the pair (Partition_ID, 64bit address) for a remote access, B uses a different format (Partition_ID, 32bit address), and C may or may not use yet another representation. Consider the following steps: B gets the remote access from A: Partition B: Partition A: | | 1. Makes remote call -------------->| | 2. Executes remote call, | computing the remote access | (A.PID, A.Adress64). | | | 3. Marshals (A.PID, A.Adress64). | | |<---------------------------4. Sends back answer message | containing the marshaled remote | access value. 5. Unmarshals the remote | access by doing the | following: | - Store the *marshaled* remote | access in some data structure. | - Set the 32bit address of the | remote access to the address of| the stored marshaled remote | access value. | | | 6. Pass on this value to the | application. | B passes the remote access value on to C: Partition B: Partition C: | | 7. Marshals the remote access | value by: | - Using the 32bit address to | retrieve the stored marshaled | representation originally | received from A. | | | 8. Makes remote call containing | the original marshaled remote | access value as received from | A.------------------------------->| | 9. Unmarshals the remote access | value in the same manner as | in 5 above, i.e., keeping the | marshaled version! | | | 10. Pass on local representative | value to the application. C makes dispatching call on the remote access value: Partition C: Partition A: | | 11. Make remote call request | using the stored marshaled | version of the remote access----->| | | | 9. Unmarshals the remote access | value, obtaining A.Address64 | | | 10. Uses A.Address64 to make the dispatching call. Note that neither B nor C need to know that A uses a 64bit local address. They can represent a remote access value locally using a simple hashing scheme even though their own representation cannot hold a 64bit address. The partitions must only agree on the definition of partition IDs and their marshaled representation, just like for any other numeric type. Whenever a remote operation is done with a remote access, the original marshaled version created by A is passed around, not the local representative value. Thus, when the value comes back to A, e.g., in a dispatching call, A can unmarshal it and recreate its own 64bit address despite the value having passed through numerous partitions where it could not be represented in unmarshaled form. (5) An application may use representation items for types declared in pure, shared passive, remote types, or remote call interface units. Since the same sources (except possibly for the standard packages) are used on all nodes, these types must have the same representa- tions. Well, yes. But in this case, the application developer is respons- ible. He should know what he's doing. If he specifies a certain representation, and the implementation cannot implement it, compilation will fail. Therefore, this case doesn't matter at all for heterogeneous distributed systems. In summary, I see no compelling reason to require identical representations for library-level types declared in preelaborated library units or in the declarations of remote types or remote call interface library units. I think it is sufficient to require that all types declared in the standard library units declared pure have the same declaration on all nodes in the distributed system. (For application-defined types, this is trivially true for any type declared in a pure, shared passive, remote types, or remote call interface unit, as the same source is used on any node.) Thus the semantics of the types are the same on all nodes, and the overall behavior will be consistent. Is there some other reason for E.2(13)? If so, I'd like to know. If not, I'd very much like to see the issue of representation cleared up, maybe in the way I proposed above. Best regards, Thomas Wolf -- ---------------------------------------------------------------------- Thomas Wolf - Swiss Federal Institute of Technology - CH-1015 Lausanne e-mail: wolf@di.epfl.ch www: http://lglwww.epfl.ch/~wolf/ *********************************************************** !topic Ada 95 and Heterogeneous Distributed Systems !reference RM95-E(6), RM-95-E.2(13) !from Anthony Gargaro 1998-08-19 !reference 1998-15886.a Thomas Wolf 1998-8-18 <> !discussion >Second, E.2(13) seems overly restrictive to me. It means that Ada 95 >supports heterogeneous distributed systems only if the implementation >manages to use the same representation for a type on all nodes. I agree that such an interpretation does appear overly restrictive. For a distributed system comprising heterogeneous processing nodes, it seems reasonable that "same representation" should be interpreted as pertaining to "same stream representation." *********************************************************** !from Randy Brukardt At the St. Quentin meeting, we discussed this issue at length. The discussion eventually converged on the idea that the paragraph in question is over- specification. The requirement is that shared and remote types work, not that any particular method be used to cause them to work. For homogeneous systems, it probably is easier for an implementation to follow this rule, while for a heterogeneous system, this may be required (in a shared memory system, such as a VME bus with two different processors) or impossible (such as floating point on a VAX and PC). Note that the stream representation of scalar types is implementation-defined. This gives the implementation freedom to use an architecture-neutral format if required for a distributed implementation. Robert Dewar offered an example of a similar over-specification: "For the operation "+", the implementation should emit a Add instruction if one exists for the target." While this obviously makes sense, it would prevent some optimizations (such as using a Subtract operation if the operand was always negative). The language should only be concerned that the feature works as specified, not that it be implemented in specific ways. After meeting aside: I wonder if the standard includes enough information to define "correct behavior" without some form of this paragraph. The intent is that the value of an object in a shared passive package, or of a remote type, is interpreted the same way in each partition. The old paragraph provided that via over-specification - is saying it still necessary?? The author of the original question suggested that requiring that all standard types (in Pure packages) have the same definition in all partitions. Is this needed? It seems to be needed to prevent different partitions having different semantics for shared types. An alternative wording for the rule would be: The implementation shall support remote access of each type used in a declared pure or shared passive library unit, or in the declaration of a remote types or remote call interface library unit. Such access must insure consistent values in each partition. I didn't use this because "consistent values" is too hard to define. In addition, the actual requirement on the implementation (that the standard types used have the same semantics, implying identical definitions) is hard to see. *********************************************************** From: Jean-Pierre Rosen[SMTP:rosen.adalog@WANADOO.FR] Sent: Tuesday, October 13, 1998 2:13 AM Subject: Re: AI-0208 >!summary 98-10-10 > >For the purposes of this AI, we introduce the term "shareable >library package". Such a package is a Declared Pure or Shared Passive library >package, or the definition of a Remote Types or Remote Call Interface library >package. I don't think this term is correct. We are not talking about packages, but types. A declared pure package is not shared, but can declare types that can be shared. Moreover, I didn't see where this term was used in the rest of the AI... >!wording 98-10-10 > >Replace E.2(13) by: > >The definition of each type used in a declared pure or shared passive library >unit, or in the declaration of a remote types or remote call interface library >unit shall be the same. This means that each type must have the same bounds, >digits value, etc. (Note: This constrains standard types to have identical >definitions in a heterogenous distributed system; other types must always >have identical definitions, as they .) This is already ensured by normal rules of the language. In the annex E model, we are talking only of a single *program*, therefore each package, including Standard, is present only once (although possibly duplicated at run time). This may require some magic in the case of heterogeneous systems. The conclusion we reached, as far as I remember, was to keep E.2(13) almost as is, with a statement that "representation" addressed the implementation-defined representation of elementary types in a stream. >Such heterogeneous systems have been used in avionics to insure that answers >calculated are independent of implementation and processor errors. This is >done by calculating answers on several different processors (each with its >own program), and comparing them. Ada should support the construction of >such systems. Note that if they are different *programs*, we are out of the scope of annex E. >Completely striking the rule goes too far, however. We need to require that >all sharable types in a distributed program have the same semantics. This is >trivially true in a homogeneous system and for user-defined types, but for a >heterogeneous system, the implementation-defined standard types could >vary without this rule. For instance, if Integer has a different range in two >partitions of the same program, the value sets for a shared passive object >could be different. Not under current rules. >The Pure standard packages which contain implementation-defined definitions >are Standard, Interfaces, Interfaces.C, Interfaces.Fortran. These are the only >packages affected by the rule. Id. *********************************************************** From: Pascal Leroy[SMTP:phl@Rational.Com] Sent: Tuesday, October 13, 1998 7:34 AM Subject: Re: AI-0208 > Here is my write up for AI-208. Note that the "standard type" issue wasn't > discussed at the meeting, but I believe that the original questioner was > correct on this issue. The conclusion of the discussion during the meeting was to remove paragraph E.2(13) entirely. I still think it was the right decision. I certainly disagree with most of the new write-up. The wording has: "The definition of each type ... shall be the same." How do you define "the same"? If you try to define this term, you run into the issue of which differencs are acceptable and which aren't. We carefully avoided this issue by using the vague phrase "semantically significant" in E.3(5). The wording could/should be phrased in terms of "semantically significant" differences, but since this is an unspecified notion, it doesn't guarantee much. More importantly, I think that the restriction on standard types is neither necessary nor sufficient. The AI as written precludes an heterogeneous implementation with a 32-bit Integer on one node and a 64-bit Integer on another node. I am not sure why we need this restriction. Since the exchange of data is phrased in terms of streams, an attempt to pass a value larger than 2 ** 31 - 1 from the 64-bit machine to the 32-bit machine will raise C_E as per 13.13.2(35). The discussion section states that this could cause bounding errors, but I think that's incorrect. It just means that the implementation has to perform extra work: it cannot just dump bytes in shared memory without checking. That may be expensive/complex to implement, but that's not a reason to disallow such an implementation. The requirement that the types be "the same" does not achieve the intended effect in the case of floating-point types. The fact that two types have the same digits and bounds does not guarantee that they have the same physical representation: they could have different Machine_Radix, one could have denorm numbers and the other not, etc. I propose to strike out E.2(13) and assume that implementors will do the right thing. Pascal *********************************************************** From: Robert Dewar[SMTP:dewar@GNAT.COM] Sent: Tuesday, October 13, 1998 7:45 AM Subject: Re: AI-0208 <> I think the change to semantically significant is reasonable <> I think it is reasonable to preclude such an implementation. It is bad enough to use unspecified standard types *at all*, but to use them in the context of heterogenous implementations of distribution where the types have "semantically significant" differences seems complete nonsense to me, and I see no reason for the RM to encourage or permit such usage. Furthermore, even a slight encouragement to implement this will add a layer of inefficiency to heterogenous distribution. Note that you have to use something like XDR to write out data for heterogensou stuff, fair enough, but you can still assume to know *what* you are reading, i.e. is it a 4-byte or 16-byte integer. If you are not allowed to know that, you need an even more heroic format for data interchange, and it is not worth it simply to allow these predefined types. Which all acts as a reminder, I am going to put in a warning in our implementation of shared passive if people use standard types in the shared passive package :-) *********************************************************** From: David Emery[SMTP:emery@MITRE.ORG] Sent: Tuesday, October 13, 1998 8:20 AM Subject: Re: AI-0208 From a naive user's perspective, I have a few questions: 1. what type should I use for "a convenient integer"? A good example is the index for a string. I don't need to constrain the range of values, but I just want an efficient integral type. 2. What will be the effect of all this on passing strings? dave David Emery, The MITRE Corp, emery@mitre.org Reston: +1 703 883 7606, fax: 883-6143; Pentagon: +1 703 695-9999, fax 695-5213 *********************************************************** From: Robert Dewar[SMTP:dewar@GNAT.COM] Sent: Tuesday, October 13, 1998 8:52 AM Subject: Re: AI-0208 For shared data in a heterogenous environment, you definitely need to say WHAT integer, and the idea of an integer that is convenient on all possible architectures is dubious! For strings, in GNAT, we assume that bounds are always 32-bits regardless. That will always be true for GNAT implementations, but you are right, it is potentially troublesome for any implementation that is inconsistent here. *********************************************************** From: Randy Brukardt[SMTP:Randy@RRSOFTWARE.COM] Sent: Tuesday, October 13, 1998 12:31 PM Subject: Re: AI-0208 >>For the purposes of this AI, we introduce the term "shareable >>library package". Such a package is a Declared Pure or Shared Passive library >>package, or the definition of a Remote Types or Remote Call Interface library >>package. >I don't think this term is correct. We are not talking about packages, but types. A declared >pure package is not shared, but can declare types that can be shared. >Moreover, I didn't see where this term was used in the rest of the AI... It's used in several places in the discussion. Without it, the discussion is either unreadable or technically incorrect. We use it to talk about the places where the rule applies (the original rule, or the revised rule). Note that it is NOT used in the revised wording. If you have a better suggestion, please make it. >The conclusion we reached, as far as I remember, was to keep E.2(13) almost as is, with a >statement that "representation" addressed the implementation-defined representation of >elementary types in a stream. Your memory is faulty. See the minutes. Randy. *********************************************************** From: Jean-Pierre Rosen[SMTP:rosen.adalog@WANADOO.FR] Sent: Wednesday, October 14, 1998 3:22 AM Subject: Re: AI-0208 >>>For the purposes of this AI, we introduce the term "shareable >>>library package". Such a package is a Declared Pure or Shared Passive >library >>>package, or the definition of a Remote Types or Remote Call Interface >library >>>package. >>I don't think this term is correct. We are not talking about packages, but >types. A declared >pure package is not shared, but can declare types that >can be shared. >>Moreover, I didn't see where this term was used in the rest of the AI... > >It's used in several places in the discussion. Without it, the discussion >is either >unreadable or technically incorrect. We use it to talk about the places >where the >rule applies (the original rule, or the revised rule). Note that it is NOT >used in the >revised wording. If you have a better suggestion, please make it. In the discussion, "shareable" is spelled "sharable", which explains why a quick search didn't find it... Note that in one occurrence (in a total of three), you are talking about sharable *types*, which is better in my view. Anyway, I don't think we need this notion anyway (see below). >>The conclusion we reached, as far as I remember, was to keep E.2(13) >almost as is, with a >statement that "representation" addressed the >implementation-defined representation of >elementary types in a stream. > >Your memory is faulty. See the minutes. The minutes say the agreement was to remove the paragraph, not to change it. I reread the AI, and now I see why you want to rephrase it this way. The question actually assumes that in an heterogeneous implementation, each partition gets a *different* Standard package. However, I don't think this is correct. The model is that there is only one set of packages for the whole *program* (i.e. for all partitions). Standard is a pure package, therefore it is duplicated in each partition. Since each partition is elaborated independantly, types defined in Standard (as well as in any other duplicated package) can have different representations; however, there is only one *definition* of the standard types, and therefore no risk of discrepancies. We decided to remove the paragraph completely on the ground that an implementation was required to work, and that it automatically implied that stream representations had to be consistent. Saying that "representation" means "stream representation" is just an enforcement of this, which answers the question as stated. *********************************************************** From: Robert Dewar Sent: Wednesday, October 14, 1998 6:50 AM Subject: Re: AI-0208 <> That has got to be wrong, if you are on a heterogenous network, different platforms will have different definitions of the float types, in terms of range precision, and representation. This works just fine right now, and there is no point in having any language in the RM that suggests that it should not! *********************************************************** From: Jean-Pierre Rosen[SMTP:rosen.adalog@wanadoo.fr] Sent: Thursday, October 15, 1998 11:45 AM Subject: Re: AI-0208 -----Message d'origine----- De : Robert Dewar À : dewar@gnat.com ; rosen.adalog@wanadoo.fr Date : jeudi 15 octobre 1998 13:32 Objet : Re: AI-0208 ><of the types defined in STANDARD, or quote the place where the RM says = >that there is a different version of STANDARD for each partition. >>> > >The idea in designing Ada 95 distribution was to *allow* but not *insist* >on heterogenous processing. I find it quite unuseful to roam around in the >RM looking for ways to prevent heterogenous processing. > >Of course we can always have GNAT use a flag (perhaps --pedantic would be >just the right choice here :-) to prevent this useful functoinality so that >GNAT disallows heterogenous distribution with this flag set, so that some >god of LRM legality is satisfied, but I do not find this particularly >sensible, and it is certainly not in accord with original intent. The argument started here from an attempt to put certain conditions for compatibilty between heterogenous systems, and I argued that these conditions were already implied by the RM. My understanding is that annex E only deals with the case of ONE program, distributed among several partitions; the issue of two communicating programs is out of scope. If GNAT is able to manage two programs that communicate in a way which is compatible and mimics annex E semantics, that's certainly very useful and desirable; however it is out of the scope of the RM (and therefore nothing would ever prevent you from dealing with it any way you please). If you think that the current model is overly restrictive and should be relaxed, that makes a very good proposal for an extension. However, as long as an AI is dealing with the current RM, I see no possibility of finding the slightest allowance for partitions to have different views of STANDARD. *********************************************************** From: Robert Dewar[SMTP:dewar@gnat.com] Sent: Thursday, October 15, 1998 12:15 PM Subject: Re: AI-0208 <> We do have one program, it is a single program in the sense of Annex E, in that it is several partitions compiled from the same library. The oddity is that indeed package Stadanrd can differ. This is not at all separate programs, it is separate partitions, managed and configured as a single program across multiple machines as envisioned by annex E (for example a shared passive partition is assigned to just one active partition, as required by the Annex E model). It was always the intention of Annex E to allow for heterogenous distribution. <> Then you have your "I will only read strictly what's there now" hat on. Please take it off, and put on our "Knowing the intent, I will read the RM creatively" hat. It is a pity if the entire intent of allowing heterogenous distribution falters on such a tiny point that does not cause difficulty for implementations. To encourage an ACVC test that specifically makes sure that the floating-point characterisitcs of standard floating-point types are consistent across partitions, and regard an implemnentation which *permits* this as non-conforming seems idle nonsense. Why nonsense? Because it is entirely unhelpful Why idle? becuase we can always put the unhelpful behavior (and hence pass the ACVC test) under control of the --pedantic switch. I certainly agree that we have an RM glitch here, one of many, normally the ARG is in the business of solving glitches, not digging its heals in and insisting on being unhelpful. After all this AI is supposed to be *helping* the cause of heterogenous distribution (it is completely irrelevant for homegenous distribution as far as I can see), so the whole AI is junk if you can't solve the problem of package Standard. To me all we need is an implementation permission allowing the implementation a bit of freedom here. JPR, I suggest you take a look at how GLADE works, to better understand the model here. Your reference to separate programs makes me think that you have not looked at how Annex E stuff works in a distributed environment. *********************************************************** From: Robert Dewar[SMTP:dewar@gnat.com] Sent: Friday, October 16, 1998 6:34 AM Subject: Re: AI-0208 <> Absolutely, especially in the case of "unfortunately ... overlooked". That is what the ARG/AI process is all about. After all, it was an extremely clear requirement in Ada 83 that type x is new integer range 1 .. 10; did not define a static first subtype :-) In general I must say that I find the RM section on passive partitions amazingly thin! ***********************************************************