CVS difference for ai05s/ai05-0060-1.txt
--- ai05s/ai05-0060-1.txt 2007/12/13 04:39:37 1.2
+++ ai05s/ai05-0060-1.txt 2008/01/19 07:25:31 1.3
@@ -315,129 +315,6 @@
****************************************************************
-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: Tucker Taft
Sent: Wednesday, August 1, 2007 11:37 AM
@@ -461,37 +338,6 @@
****************************************************************
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: Randy Brukardt
Sent: Thursday, August 2, 2007 12:19 AM
> Although it needs explicit clarification, I believe
@@ -535,397 +381,175 @@
beer. :-)
****************************************************************
-
-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).
+From: Brad Moore
+Sent: Tuesday, January 15, 2008 12:14 PM
-Streaming them yourself is MUCH less convenient!
+I have been looking into the AI assigned to me regarding potentially
+allowing limited interfaces as remote types.
-****************************************************************
-
-From: Pascal Leroy
-Sent: Friday, August 3, 2007 1:59 AM
+One of the questions raised in the discussion for the AI was whether it
+made sense for synchronous interfaces (protected and task) to be allowed
+as remote access types.
-> 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.
+The overall sense so far is that this would not fly, due to difficulties
+in defining semantics and implementing those semantics, but it would be
+interesting to see what others thought.
-At any rate, we'll need to resolve the questions raised by Tuck regarding
-anonymous access types.
+A couple of points to add to the discussion so far;
-****************************************************************
+E.4 (17) states "All forms of remote subprogram calls are potentially
+blocking operations (see 9.5.1)."
-From: Robert Dewar
-Sent: Friday, August 3, 2007 4:12 PM
+If protected interfaces were to be allowed as remote access types it
+would seem to imply that all procedures of the interface would need to
+be implemented as entries to work with the model of the protected types.
+Also, this would seem to rule out functions since those are not supposed
+to be potentially blocking.
+Maybe functions and procedures could be implemented as regular
+subprograms, but those would be local calls that could call entries of
+the protected object which would be remote.
-> 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?
+Here are some relevant excerpts from private emails on this topic.
-****************************************************************
+---------------------------------------
-From: Robert Dewar
-Sent: Friday, August 3, 2007 4:19 PM
+From: Bob Duff
+Sent: Tuesday, Jan 08, 2008 7:11 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.
+Brad Moore wrote:
-****************************************************************
+> I am investigating AI05-0060. Do you think that Synchronized
+> interfaces should be allowed as remote types?
-From: Randy Brukardt
-Sent: Saturday, August 4, 2007 9:48 PM
+Protected types were designed with tightly coupled, shared memory
+multiprocessing systems in mind. So no, I don't think it would be wise to
+support synchronized interfaces as remote types. I think it would be quite
+difficult to define the semantics of distributed entry and protected subprogram
+calls, and it would no doubt be quite difficult to implement.
-> > 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.
+> synchronized capabilities considered farther in the future,
+> maybe Ada 2015?
-Getting off of soapbox...
+Well, that's up to ARG, but I doubt synchronized remote types would fly.
-****************************************************************
+---------------------------------------
-From: Robert Dewar
-Sent: Sunday, August 5, 2007 7:12 AM
+From: Ed Schonberg
+Sent: Tuesday, Jan 15, 2008 3:00 PM
-> 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.
+I don't think this will fly. Protected types are intended for
+synchronization over shared data in a common memory space. Using them
+across partitions confuses distributed systems with shared memory
+systems. For the foreseable future heterogeneous systems are with us,
+and we need different mechanisms for different layers, no?
****************************************************************
-From: Robert Dewar
-Sent: Sunday, August 5, 2007 7:12 AM
+From: Jean-Pierre Rosen
+Sent: Tuesday, January 15, 2008 2:59 PM
-> 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").
+> The overall sense so far is that this would not fly, due to difficulties
+> in defining semantics and implementing those semantics, but it would be
+> interesting to see what others thought.
+
+Hmm.. Thinking about it... What about a remote requeue?
****************************************************************
-From: Robert A. Duff
-Sent: Sunday, August 5, 2007 7:45 AM
+From: Tucker Taft
+Sent: Tuesday, January 15, 2008 3:39 PM
+
+> The overall sense so far is that this would not fly, due to difficulties
+> in defining semantics and implementing those semantics, but it would be
+> interesting to see what others thought.
+
+Based on my answers below, I don't see any insurmountable problems.
+Concocting "stub" protected/task types might be a bit tricky,
+but I suspect you could just make them very simple, with
+all of the interesting information accessible via an access
+discriminant. E.g.
+
+ type Remote_Task is task interface;
+ procedure Remote_Op_1(RT : Remote_Task; ...) is abstract;
+ function Remote_Op_2(RT : Remote_Task; ...)
+ return Integer is abstract;
+
+ ...
+
+ task type Stub_For_Remote(Comm_Info :
+ access Comm_Info_Record)
+ is new Remote_Task with
+ entry Quit_Now;
+ end Stub_For_Remote;
+ -- body probably consists of a single selective_accept
+ -- that waits to accept Quit_Now or terminate.
+
+ procedure Remote_Op_1(SFR : Stub_For_Remote; ...);
+ function Remote_Op_2(SFR : Stub_For_Remote; ...)
+ return Integer;
+ -- These calling stubs marshall the parameters
+ -- and call the PCS, and then the receiving stubs
+ -- call the corresponding operations of the "real"
+ -- task type that implements Remote_Task.
-> 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.
+> A couple of points to add to the discussion so far;
>
-> 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).
+> E.4 (17) states "All forms of remote subprogram calls are potentially
+> blocking operations (see 9.5.1)."
>
-> 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...
+> If protected interfaces were to be allowed as remote access types it
+> would seem to imply that all procedures of the interface would need to
+> be implemented as entries to work with the model of the protected types.
+
+I don't see this. Remember that there are three possibilities
+with a primitive of a protected interface. It can be implemented
+directly as a protected subprogram, it can be implemented as
+an entry (presuming it is visibly declared as a procedure), and
+it can be implemented as a "regular" subprogram which turns
+around and calls one or more protected operations. The only
+one of these that is non-blocking is the one that is implemented
+directly as a protected subprogram.
+
+> Also, this would seem to rule out functions since those are not supposed
+> to be potentially blocking.
+
+Only if they are implemented directly as a protected subprogram.
+Not if they are implemented as a "normal" subprogram.
+
+> Maybe functions and procedures could be implemented as regular
+> subprograms, but those would be local calls that could call entries of
+> the protected object which would be remote.
+
+Sorry, I don't follow this. If it is an access-to-remote
+subprogram, then any dispatching call is a remote call.
+Once you get to the "other" side, then you would call the
+implementing subprogram/protected-operation.
+
+My conclusion is that using synchronized interfaces
+is not a big problem, but that the newly proposed pragma "Implemented"
+(or whatever it is called) could not specify "By_Entry" or
+"By_Protected_Procedure" for these, since trying to
+do a requeue on one of these or expecting non-blocking
+behavior would be too difficult to accomplish.
+
+> Here are some relevant excerpts from private emails on this topic.
+
+I don't fully agree with Bob and Ed. Synchronized interfaces
+guarantee multi-thread-safe access to the underlying data.
+They don't guarantee non-blocking behavior, even for
+protected interfaces. Protected interfaces pretty much
+guarantee that there is no separate thread associated with
+the object, whereas task interfaces guarantee that there
+is at least one thread associated with the object, but that
+is about it. None of these guarantees seem to be incompatible
+with remote execution. And in fact, it would seem highly
+desirable to use synchronized interfaces for remote interfaces,
+so they could support concurrent simultaneous access from
+multiple threads potentially spread across multiple partitions.
+One might even go so far as to recommend using synchronized
+interfaces when doing things remotely.
-;-)
-
-****************************************************************
-
-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
-
-
-****************************************************************
Questions? Ask the ACAA Technical Agent