!standard A.18.2(6/2) 08-04-18 AI05-0084-1/03 !standard A.18.3(5/2) !standard A.18.5(2/2) !standard A.18.6(2/2) !standard A.18.8(2/2) !standard A.18.9(2/2) !standard A.18.17(5/3) !class binding interpretation 08-01-18 !status ARG Approved 6-0-2 08-02-25 !status work item 08-01-18 !status received 08-01-10 !priority Low !difficulty Medium !qualifier Omission !subject Pragma Remote_Types for Container library units !summary All of the language-defined container packages have pragma Remote_Types, unless they have pragma Pure (as for Ada.Containers itself). !question Should the language defined container packages support remote subprogram calls? (Yes.) !recommendation (See Summary.) !wording Add pragma Remote_Types to the following packages, immediately after pragma Preelaborate: Ada.Containers.Vectors (A.18.2(6/2)), Ada.Containers.Doubly_Linked_Lists (A.18.3(5/2)), Ada.Containers.Hashed_Maps (A.18.5(2/2)), Ada.Containers.Ordered_Maps (A.18.6(2/2)), Ada.Containers.Hashed_Sets (A.18.8(2/2)), Ada.Containers.Ordered_Sets (A.18.9(2/2)), and Ada.Containers.Indefinite_Holders (A.18.17(5/3)). [From AI05-0069-1.] Note that the other indefinite versions don't need a wording change, as they are copied from the definite versions. !discussion This means that containers (for example, objects of type Vector) can be used remotely. The Cursor types, however, are defined to raise Program_Error when the predefined streaming attributes are used. Note: This AI depends on AI05-0060-1 that clarifies which access types are remote access types. None of the types in the container packages are intended to be remote access types. If the implementation does not support Annex E features, then pragma Remote_Types can be omitted by a permission added by AI05-0060-1. It has been suggested that containers can already be streamed "by hand". However, this is much less convenient for the Annex E user than making them full-fledged remote types packages. We also fix the third is in A.18.5(2/2) to be in bold, as it is a reserved word. !corrigendum A.18.2(6/2) @drepl @xcode<@b @b Index_Type @b <@>; @b Element_Type @b; @b "=" (Left, Right : Element_Type) @b Boolean @b <@>; @b Ada.Containers.Vectors @b @b Preelaborate(Vectors);> @dby @xcode<@b @b Index_Type @b <@>; @b Element_Type @b; @b "=" (Left, Right : Element_Type) @b Boolean @b <@>; @b Ada.Containers.Vectors @b @b Preelaborate(Vectors); @b Remote_Types(Vectors);> !corrigendum A.18.3(5/2) @drepl @xcode<@b @b Element_Type @b; @b "=" (Left, Right : Element_Type) @b Boolean @b <@>; @b Ada.Containers.Doubly_Linked_Lists @b @b Preelaborate(Doubly_Linked_Lists);> @dby @xcode<@b @b Element_Type @b; @b "=" (Left, Right : Element_Type) @b Boolean @b <@>; @b Ada.Containers.Doubly_Linked_Lists @b @b Preelaborate(Doubly_Linked_Lists); @b Remote_Types(Doubly_Linked_Lists);> !corrigendum A.18.5(2/2) @drepl @xcode<@b @b Key_Type @b; @b Element_Type @b; @b Hash (Key : Key_Type) @b Hash_Type; @b Equivalent_Keys (Left, Right : Key_Type) @b Boolean; @b "=" (Left, Right : Element_Type) @b Boolean is <@>; @b Ada.Containers.Hashed_Maps @b @b Preelaborate(Hashed_Maps);> @dby @xcode<@b @b Key_Type @b; @b Element_Type @b; @b Hash (Key : Key_Type) @b Hash_Type; @b Equivalent_Keys (Left, Right : Key_Type) @b Boolean; @b "=" (Left, Right : Element_Type) @b Boolean @b <@>; @b Ada.Containers.Hashed_Maps @b @b Preelaborate(Hashed_Maps); @b Remote_Types(Hashed_Maps);> !corrigendum A.18.6(2/2) @drepl @xcode<@b @b Key_Type @b; @b Element_Type @b; @b "<" (Left, Right : Key_Type) @b Boolean @b <@>; @b "=" (Left, Right : Element_Type) @b Boolean @b <@>; @b Ada.Containers.Ordered_Maps @b @b Preelaborate(Ordered_Maps);> @dby @xcode<@b @b Key_Type @b; @b Element_Type @b; @b "<" (Left, Right : Key_Type) @b Boolean @b <@>; @b "=" (Left, Right : Element_Type) @b Boolean @b <@>; @b Ada.Containers.Ordered_Maps @b @b Preelaborate(Ordered_Maps); @b Remote_Types(Ordered_Maps);> !corrigendum A.18.8(2/2) @drepl @xcode<@b @b Element_Type @b; @b Hash (Element : Element_Type) @b Hash_Type; @b Equivalent_Elements (Left, Right : Element_Type) @b Boolean; @b "=" (Left, Right : Element_Type) @b Boolean @b <@>; @b Ada.Containers.Hashed_Sets @b @b Preelaborate(Hashed_Sets);> @dby @xcode<@b @b Element_Type @b; @b Hash (Element : Element_Type) @b Hash_Type; @b Equivalent_Elements (Left, Right : Element_Type) @b Boolean; @b "=" (Left, Right : Element_Type) @b Boolean @b <@>; @b Ada.Containers.Hashed_Sets @b @b Preelaborate(Hashed_Sets); @b Remote_Types(Hashed_Sets);> !corrigendum A.18.9(2/2) @drepl @xcode<@b @b Element_Type @b; @b "<" (Left, Right : Element_Type) @b Boolean @b <@>; @b "=" (Left, Right : Element_Type) @b Boolean @b <@>; @b Ada.Containers.Ordered_Sets @b @b Preelaborate(Ordered_Sets);> @dby @xcode<@b @b Element_Type @b; @b "<" (Left, Right : Element_Type) @b Boolean @b <@>; @b "=" (Left, Right : Element_Type) @b Boolean @b <@>; @b Ada.Containers.Ordered_Sets @b @b Preelaborate(Ordered_Sets); @b Remote_Types(Ordered_Sets);> !corrigendum A.18.17(5/3) @drepl @xcode<@b @b Element_Type (<>) @b; @b "=" (Left, Right : Element_Type) @b Boolean @b <@>; @b Ada.Containers.Indefinite_Holders @b @b Preelaborate (Indefinite_Holders);> @dby @xcode<@b @b Element_Type (<>) @b; @b "=" (Left, Right : Element_Type) @b Boolean @b <@>; @b Ada.Containers.Indefinite_Holders @b @b Preelaborate (Indefinite_Holders); @b Remote_Types (Indefinite_Holders);> !ACATS Test Create an ACATS C-Test that tries remote streaming of containers. !appendix From: Robert A. Duff Sent: Saturday, June 30, 2007 9:27 AM There is no pragma Remote_Types in the containers packages (Ada.Containers.Vectors and friends). Is this an oversight? Is there some reason why these can't be Remote_Types? Note that Remote_Types was added after the fact to some Ada 95 packages, such as Ada.Finalization. **************************************************************** From: Pascal Leroy Sent: Wednesday, August 1, 2007 2:33 AM > There is no pragma Remote_Types in the containers packages > (Ada.Containers.Vectors and friends). Is this an oversight? > Is there some reason why these can't be Remote_Types? I see two difficulties with this. The first difficulty is the streaming of cursors. This is an issue that we discussed during the design of the containers, and we have rules (e.g., A.18.2(88/2)) to the effect that streaming a cursor raises P_E. The reason is that we could not figure out what sense it makes to stream a cursor: a cursor typically includes a pointer to a container, and surely we do not want to stream the associated container when we stream a cursor. The only alternative that I can think of would be for the cursor to record some form of network-wide identity of the associated container, but that seems awfully expensive. And I don't believe that we want to say that only some types in these library units are remote types. The second difficulty has to do with remote access types. Remember that access types declared in the visible part of a Remote_Types package are remote access types, and are subject to specific rules (see E.2.2). Now there are a number of anonymous access-to-subprogram types in the visible part of the containers, and if these types were remote access-to-subprogram types, you could only pass in remote subprograms. That seems like an unacceptable burden for the user: they would have to make all sorts of units RCI for no good reason, and to live with the associated restrictions. Not to mention that there would probably be a significant overhead in parameter passing and subprogram calls (unless the implementation is very smart and detects that the called subprogram is actually in the same partition). Overall, I'd say that it would create too much trouble for users and implementers. If someone really wants to transport containers, they'll do that explicitly by using the streaming attributes (unlike cursors, containers can be streamed, of course). **************************************************************** From: Robert A. Duff Sent: Wednesday, August 1, 2007 10:01 AM Hmm -- you're one day too late. ;-) I actually implemented it yesterday. It was not trivial -- I couldn't just add the Remote_Types pragma all over the place, because we had some internal implementation packages that needed to be turned into pragma-Pure, and that required stirring the code around quite a bit. I haven't checked it into CVS yet... ... > The first difficulty is the streaming of cursors. This is an issue that > we discussed during the design of the containers, and we have rules (e.g., > A.18.2(88/2)) to the effect that streaming a cursor raises P_E. The > reason is that we could not figure out what sense it makes to stream a > cursor: a cursor typically includes a pointer to a container, and surely > we do not want to stream the associated container when we stream a cursor. > The only alternative that I can think of would be for the cursor to record > some form of network-wide identity of the associated container, but that > seems awfully expensive. And I don't believe that we want to say that > only some types in these library units are remote types. I don't buy the first difficulty. Sure, you can't stream cursors, and you get a run-time error if you try. Shrug. The goal is to be able to send vectors and mappings and whatnot. > The second difficulty has to do with remote access types. Remember that > access types declared in the visible part of a Remote_Types package are > remote access types, and are subject to specific rules (see E.2.2). Now > there are a number of anonymous access-to-subprogram types in the visible > part of the containers, and if these types were remote > access-to-subprogram types, you could only pass in remote subprograms. > That seems like an unacceptable burden for the user: they would have to > make all sorts of units RCI for no good reason, and to live with the > associated restrictions. Not to mention that there would probably be a > significant overhead in parameter passing and subprogram calls (unless the > implementation is very smart and detects that the called subprogram is > actually in the same partition). The second, on the other hand, might be a real problem. Is it really the intent that anonymous access types are remote if they appear in a Remote_Types package? Are you saying that the following example would be illegal, if Vectors were Remote_Types, since Process is not a remote procedure? with Ada.Containers.Vectors; use Ada.Containers; procedure Example is package My_Vectors is new Vectors (Index_Type => Positive, Element_Type => Character); use My_Vectors; V : Vector := To_Vector (New_Item => 'A', Length => 10); procedure Process(Element : in out Character) is begin Element := 'x'; end Process; begin Update_Element (V, Index => 4, Process => Process'Access); end Example; In fact, GNAT does not complain about the above (using my private version that has pragma Remote_Types in all the Containers packages, except the ones that are Pure). **************************************************************** From: Randy Brukardt Sent: Thursday, August 2, 2007 12:10 AM ... > > The first difficulty is the streaming of cursors. This is an issue that > > we discussed during the design of the containers, and we have rules (e.g., > > A.18.2(88/2)) to the effect that streaming a cursor raises P_E. The > > reason is that we could not figure out what sense it makes to stream a > > cursor: a cursor typically includes a pointer to a container, and surely > > we do not want to stream the associated container when we stream a cursor. > > I don't buy the first difficulty. Sure, you can't stream cursors, and you get > a run-time error if you try. Shrug. The type Cursor violates E.2.2(8/2) in that it doesn't support external streaming. I realize that the implementation of a containers package in Ada probably would fool the compiler into thinking it did (because there would be a user-defined stream attribute), but nothing in the definition of the description of the containers packages says or implies that these support external streaming. > The goal is to be able to send vectors and mappings and whatnot. You can stream those yourself, and you don't get into trouble with the construction of the packages if you do so. Ada doesn't allow you do define *just* those types as remote types (a much more useful definition than trying to make the entire package remoteable). **************************************************************** From: Robert Dewar Sent: Thursday, August 2, 2007 6:20 AM > You can stream those yourself, and you don't get into trouble with the > construction of the packages if you do so. Ada doesn't allow you do define > *just* those types as remote types (a much more useful definition than > trying to make the entire package remoteable). Streaming them yourself is MUCH less convenient! **************************************************************** From: Pascal Leroy Sent: Friday, August 3, 2007 1:59 AM > Hmm -- you're one day too late. ;-) I actually implemented > it yesterday. It was not trivial -- I couldn't just add the > Remote_Types pragma all over the place, because we had some > internal implementation packages that needed to be turned > into pragma-Pure, and that required stirring the code around > quite a bit. I haven't checked it into CVS yet... This is another reason why I am opposed to making these units Remote_Types. A Remote_Types unit can only depend on pure, shared passive or remote type units. This imposes all sorts of restrictions on the auxiliary units used to implement the containers, notably with respect to access types. For instance, our implementation uses an auxiliary unit to manage binary trees. This unit is, of course, full of access types. I didn't try to see what happens if I slap a categorization pragma on it, but on the surface things don't look good. In fact having to deal with pragma Preelaborate all over the place was already a significant pain. I don't see why we would make everybody's life complicated for an annex which, as far as I can tell, is only supported by one implementation. Maybe the solution is to say that the containers are Remote_Types iff the implementation supports annex E. That couldn't create portability issues: if you care about annex E, you better use GNAT anyway, so portability is moot. At any rate, we'll need to resolve the questions raised by Tuck regarding anonymous access types. [See AI05-0060-1 - ED.] **************************************************************** From: Robert Dewar Sent: Friday, August 3, 2007 4:12 PM > I don't see why we would make everybody's life complicated for an annex > which, as far as I can tell, is only supported by one implementation. > Maybe the solution is to say that the containers are Remote_Types iff the > implementation supports annex E. That couldn't create portability issues: > if you care about annex E, you better use GNAT anyway, so portability is > moot. why not do that for ALL instances of this pragma in the standard libraries? **************************************************************** From: Robert Dewar Sent: Friday, August 3, 2007 4:19 PM > This is another reason why I am opposed to making these units > Remote_Types. A Remote_Types unit can only depend on pure, shared passive > or remote type units. This imposes all sorts of restrictions on the > auxiliary units used to implement the containers, notably with respect to > access types. That's an artifact of your implementation, not a language issue (the language does not say the bodies have to be in Ada). What GNAT does to deal with MANY such problems in implementing the run time is to make categorization errors warnings when compiling run time library files, and then we suppress the warnings where needed (after verifying as is almost always the case, that the warning is a junk consequence of the RM rules that in fact does not intefere with the implementation). In your case you can completely ignore categorization errors from remote types in implementing your run time, since they are always junk if you have no Annex E. > For instance, our implementation uses an auxiliary unit to > manage binary trees. This unit is, of course, full of access types. I > didn't try to see what happens if I slap a categorization pragma on it, > but on the surface things don't look good. In fact having to deal with > pragma Preelaborate all over the place was already a significant pain. We just completely eliminated this pain by the approach above, I really cannot imagine trying to obey the silly Preelaborate categorization dependency rules in the implementation of the run time (silly because Preelaborate is a messed up gizmo which tries to be too many things to too many language features) > I don't see why we would make everybody's life complicated for an annex > which, as far as I can tell, is only supported by one implementation. Equally you don't want to make the containers difficult for users of this Annex with the implementation that *does* support this Annex. > Maybe the solution is to say that the containers are Remote_Types iff the > implementation supports annex E. That couldn't create portability issues: > if you care about annex E, you better use GNAT anyway, so portability is > moot. moot = arguable, undecided, which is not quite what you mean here. However the proposal certainly seems reasonable. It says that the Remote_Types pragmas in these units are only there if you support Annex E, so there is no portability issue anyway. Your proposal is entirely portable, so I don't understand the claim that it is moot. **************************************************************** From: Randy Brukardt Sent: Saturday, August 4, 2007 9:48 PM > > This is another reason why I am opposed to making these units > > Remote_Types. A Remote_Types unit can only depend on pure, shared passive > > or remote type units. This imposes all sorts of restrictions on the > > auxiliary units used to implement the containers, notably with respect to > > access types. > > That's an artifact of your implementation, not a language issue (the > language does not say the bodies have to be in Ada). What GNAT does > to deal with MANY such problems in implementing the run time is to > make categorization errors warnings when compiling run time library > files, and then we suppress the warnings where needed (after verifying > as is almost always the case, that the warning is a junk consequence > of the RM rules that in fact does not intefere with the implementation). I dislike this strategy [which, let me hasen to say, is perfectly legitimate]. I prefer to "eat my own dogfood" -- that is, use the compiler and language as they were designed. That's especially true for packages like the containers which are easy to write in pure Ada. If there is something in our compiler implementation that is causing pain, then it becomes a priority to fix that in someway (because it is likely to be causing pain to users as well). Similarly, if there is something in the language that is causing pain, then that should be a priority to get fixed. We enforce pure and preelaborate restrictions everywhere we can. Even our assembler makes a half-hearted attempt to enforce this restrictions (it doesn't allow library level objects in pure units, for instance). If it is necessary to end-run around the restrictions of Pure or Preelaborate to get anything done, then I have to wonder what the value of having it is. End users will have the same needs to avoid the restrictions, but they don't have the same ability to do so. [And any ability they do have is a bug in the language, not a feature.] Which suggests that either the restrictions need to be revisited (to some extent, we did that this time) or that the whole idea be dropped. Getting off of soapbox... **************************************************************** From: Robert Dewar Sent: Sunday, August 5, 2007 7:12 AM > I dislike this strategy [which, let me hasen to say, is perfectly > legitimate]. I prefer to "eat my own dogfood" -- that is, use the compiler > and language as they were designed. That's especially true for packages like > the containers which are easy to write in pure Ada. If there is something in > our compiler implementation that is causing pain, then it becomes a priority > to fix that in someway (because it is likely to be causing pain to users as > well). Similarly, if there is something in the language that is causing > pain, then that should be a priority to get fixed. Note that there is an important difference between implementing the predefined packages and applications programming. In the latter it is normal and frequent to try to make something preelaborate, and then find out there is a restriction (perhaps sensible, perhaps junk) that prevents it. You simply back off in that case (or perhaps when using GNAT, use pragma Restrictions (No_Elaboration_Code), which is probably what you wanted anyway). But in the case of the predefined libraries you can't back off in this way, so you have to kludge things. No big deal! > If it is necessary to end-run around the restrictions of Pure or > Preelaborate to get anything done, then I have to wonder what the value of > having it is. Indeed pragma Preleaborate is a seriously messed up feature in my opinion. It tries to do three things at a time, and does not get any of them quite right. **************************************************************** From: Robert Dewar Sent: Sunday, August 5, 2007 7:12 AM > I dislike this strategy [which, let me hasen to say, is perfectly > legitimate]. I prefer to "eat my own dogfood" -- that is, use the compiler > and language as they were designed. That's especially true for packages like > the containers which are easy to write in pure Ada. If there is something in > our compiler implementation that is causing pain, then it becomes a priority > to fix that in someway (because it is likely to be causing pain to users as > well). Similarly, if there is something in the language that is causing > pain, then that should be a priority to get fixed. Anyway, even if you think this, it is a VERY thin justification for removing a useful feature from the language ("sorry you can't do that, not because it is an ill-chosen feature, or not useful, but because implementing it would offend my aesthetic senses/prefernces"). **************************************************************** From: Robert A. Duff Sent: Sunday, August 5, 2007 7:45 AM > I dislike this strategy [which, let me hasen to say, is perfectly > legitimate]. I prefer to "eat my own dogfood" -- that is, use the compiler > and language as they were designed. That's especially true for packages like > the containers which are easy to write in pure Ada. In most cases, I agree. In fact, I was able to convert the containers to Remote_Types using pure Ada. I had to change an internal generic package to pragma-Pure, which required adding "for T'Storage_Size use 0;" on an access type, which required adding a new access type for allocation, and defining New_Blah and Free_Blah routines, which do new/U_D, and convert the access type back and forth, which required adding "all" to the original access type. That's what I meant by stirring the code around. It was already the case that the access type was in a unit with types (no operations), and the operations were in child units, and the children were with'ed only by bodies of the containers (so these didn't need to be Pure). On the other hand, if that's too painful, the approach outlined by Robert is perfectly reasonable. Yes, it suggests that there might be something wrong with Ada, but..., well..., nobody ever claimed Ada is perfect. >...If there is something in > our compiler implementation that is causing pain, then it becomes a priority > to fix that in someway (because it is likely to be causing pain to users as > well). Similarly, if there is something in the language that is causing > pain, then that should be a priority to get fixed. > > We enforce pure and preelaborate restrictions everywhere we can. Even our > assembler makes a half-hearted attempt to enforce this restrictions (it > doesn't allow library level objects in pure units, for instance). > > If it is necessary to end-run around the restrictions of Pure or > Preelaborate to get anything done, then I have to wonder what the value of > having it is. End users will have the same needs to avoid the restrictions, > but they don't have the same ability to do so. [And any ability they do have > is a bug in the language, not a feature.] Which suggests that either the > restrictions need to be revisited (to some extent, we did that this time) or > that the whole idea be dropped. I'd be in favor of dropping pragma Preelaborate (except for those pesky "compatibility" concerns...). > Getting off of soapbox... ;-) **************************************************************** From: Robert A. Duff Sent: Sunday, August 5, 2007 7:49 AM > Maybe the solution is to say that the containers are Remote_Types iff the > implementation supports annex E. That seems like a good compromise. In fact, I think any pragma Remote_Types appearing in the core language has to be interpreted to be not-really-there if the implementation doesn't claim to support annex E. That is, you can't write a test case that can tell whether pragma Remote_Types appears in the Containers packages, without using Annex E features, so if Annex E doesn't exist, the compiler can ignore any requirements for Remote_Types. **************************************************************** From: Pascal Leroy Sent: Monday, August 6, 2007 6:14 AM > That's an artifact of your implementation, not a language > issue (the language does not say the bodies have to be in > Ada). The containers were very carefully crafted so that their bodies could be written in Ada, and in fact there are several pure Ada implementations around. As far as I am concerned, any request to change the standard in a way that would make it impossible to write them in Ada is a no-no. One reason for this is that we wanted to leave open the possibility for 3rd parties (perhaps in the free software community) to develop additional containers (e.g., synchronized, bounded, etc.) and to be able to do so without going through insane compiler-dependent drudgery. Bob tells us that it *is* actually possible to write the containers in Ada with pragma Remote_Types. Fine. But it would be irresponsible to ignore the impact on existing implementations: if it is too high, implementers will just ignore the change. > (silly because Preelaborate is > a messed up gizmo which tries to be too many things to too > many language features) I couldn't agree more, but this is water under the bridge. **************************************************************** From: Pascal Leroy Sent: Monday, August 6, 2007 6:14 AM > On the other hand, if that's too painful, the approach > outlined by Robert is perfectly reasonable. Yes, it suggests > that there might be something wrong with Ada, but..., > well..., nobody ever claimed Ada is perfect. It suggest that folks who are not compiler writers cannot develop decent containers, which sounds very wrong to me. **************************************************************** From: Robert Dewar Sent: Monday, August 6, 2007 9:05 AM All we *might* be saying is that it might not be possible to do the exact specs in the RM, that's not the same as not being able to do decent containers. And after all from the point of view of the distribution folks, decent = remote types present! Seeing as the language does not allow people to replace the bodies of Containers UNLESS they are implementors: > 4 The implementation may restrict the replacement of language-defined > compilation units. The implementation may restrict children of > language-defined library units (other than Standard). So regardless of any discussion of pragmas, you may not be able to write your own bodies to replace the ones your vendor gives you. **************************************************************** From: Randy Brukardt Sent: Monday, August 6, 2007 7:17 PM > > ... Similarly, if there is something in the language that is causing > > pain, then that should be a priority to get fixed. > > Anyway, even if you think this, it is a VERY thin justification for > removing a useful feature from the language ("sorry you can't do that, > not because it is an ill-chosen feature, or not useful, but > because implementing it would offend my aesthetic senses/prefernces"). I'm not quite sure how you managed to leap from "priority to get fixed" to "removing a useful feature"; surely, one possible fix would be to remove the feature but clearly that is the last resort. It would make more sense to try to eliminate the source of pain, and that is what I meant by the above. For me, most of my packages could logically have a Preelaborate pragma, but they can't because (1) they depend on Text_IO or similar I/O packages; (2) they depend on Calendar or on of the other timing packages; or (3) they depend on a package that has (1) or (2). I might have more trouble with the restrictions on the code, but I've never been able to check because I never get that far. (There are possible workarounds to (2) and especially (1), but they have run-time costs that aren't always appropriate.) Obviously, the best fix would be to reduce the restrictions on Preelaborate and/or find a substitute for (1) and (2). Dropping the feature altogether wouldn't be what I would prefer to do; I'd love to be able to use it because it reduces the code needed at runtime. **************************************************************** From: Robert Dewar Sent: Tuesday, August 7, 2007 3:51 AM ... > For me, most of my packages could logically have a Preelaborate pragma, but > they can't because (1) they depend on Text_IO or similar I/O packages; We deal with this by providing an I/O package with a useful subset of Text_IO capabilities that is Preelaborate. > Obviously, the best fix would be to reduce the restrictions on Preelaborate > and/or find a substitute for (1) and (2). Dropping the feature altogether > wouldn't be what I would prefer to do; I'd love to be able to use it because > it reduces the code needed at runtime. In GNAT, if what you are after is eliminating elaboration code, the preferable way to do it is pragma Restrictions (No_Elaboration_Code) for two reasons: 1. It is unit by unit 2. pragma Preelaborate does not ensure no elaboration code **************************************************************** From: Randy Brukardt Sent: Tuesday, January 15, 2008 3:12 PM ... > If the implementation does not support Annex E features, then pragma > Remote_Types is semantically invisible. Therefore, this AI cannot cause > implementation difficulty for such implementations. [If I'm wrong about that, > then I recommend that we say so by fait -- that is, an Implementation > Permission that allows a non-Annex-E implementation to completely ignore > pragma Remote_Types. But I don't think such permission is actually > necessary.] I disagree with this; I think we need an explicit permission for this, but not the one you are describing. It makes sense for an implementation to enforce the restrictions of Remote_Types etc. even though no Annex E semantics are attached to such units. It's natural to implement these at the same time Pure and Preelaborate are done, because they are closely related. And unless an implementer is sure that they're never going to implement Annex E (and who is like that?), it makes sense to include that support (and it is harmless. Janus/Ada does that with the pragmas. Telling us to take that code out because we don't otherwise support Annex E is silly (does that really help any Ada users??), and telling us to implement an end-run mode so we can implement the containers packages is just as silly (does that benefit any Ada users??). So I think there should be an explicit permission to omit the pragmas from language-defined packages if Annex E is not fully supported. **************************************************************** From: Jean-Pierre Rosen Sent: Tuesday, January 15, 2008 3:36 PM > So I think there should be an explicit permission to omit the pragmas from > language-defined packages if Annex E is not fully supported. > If the pragma is not supported, it should be ignored - it is certainly not allowed to do something else. Do we even need that permission? **************************************************************** From: Randy Brukardt Sent: Tuesday, January 15, 2008 4:05 PM But it is perfectly OK to support the pragma and not support the creation of distributed partitions. (That's the current state of Janus/Ada.) In that case, there is no value to having it specified on the containers library (or anything other library level routines) for that implementation. But requiring it prevents all clever implementations of the containers library -- essentially you are required to either have extremely expensive cursors or to detect few errors making pretty much everything to be erroneous. > Do we even need that permission? I think we do; the only alternative is to force the removal of any partially implemented Annex E code from compilers and that isn't going to help anyone. (Surely, once it is removed it is never coming back. In which case Annex E is doing more harm than good in the standard). **************************************************************** From: Tucker Taft Sent: Tuesday, January 15, 2008 4:28 PM > ... But > requiring it prevents all clever implementations of the containers > library -- essentially you are required to either have extremely expensive > cursors or to detect few errors making pretty much everything to be > erroneous. I may be missing something, but why are cursors expensive? I believe Bob Duff is suggesting that streaming them raises Program_Error. **************************************************************** From: Randy Brukardt Sent: Tuesday, January 15, 2008 4:45 PM It's got nothing to do with streaming, it has to do with detecting bad ones (dangling or slid). That can be done by making them controlled and linking them together (so bad ones can be nulled out), but that is relatively expensive. There are cheaper alternatives for cursors that detect problems (rather than just allowing everything to be erroneous), but they require more complex data structures on the element/node end, and that appears to be disallowed by pragma Remote_Types (because the types needed are illegal). I note that Bob seems to predicate his AI on a better definition on what are remote access types, and not having any idea what that means at this point, it might be the case that there is no actual problem in the end. But I'm not sure that it is possible to have access types in a remote types package that aren't remote access types -- because what are they otherwise? How could they work? **************************************************************** From: Robert A. Duff Sent: Tuesday, January 15, 2008 5:49 PM > Will do. Thanks. > So I think there should be an explicit permission to omit the pragmas from > language-defined packages if Annex E is not fully supported. I am suggesting that an implementation that does not support Annex E can (if it likes) comment out all pragmas Remote_Types appearing in language-defined packages. If this requires an Impl Perm, then so be it. I am not suggesting they change their compilers in any way. The goal of this AI is to allow Annex E users to send containers, while causing zero trouble for implementations that do not support Annex E, or that support only part of it (e.g. support some of the pragmas). **************************************************************** From: Jean-Pierre Rosen Sent: Wednesday, January 16, 2008 3:07 AM > But it is perfectly OK to support the pragma and not support the creation of > distributed partitions. (That's the current state of Janus/Ada.) In that > case, there is no value to having it specified on the containers library (or > anything other library level routines) for that implementation. But > requiring it prevents all clever implementations of the containers > library -- essentially you are required to either have extremely expensive > cursors or to detect few errors making pretty much everything to be > erroneous. But Remote_Type imposes restriction only to the declaration of the package. I don't think forbidding variables in the visible part is a problem. So the only issue is the requirement to support external streaming. Does it really prevent more efficient implementations? ****************************************************************