CVS difference for ai05s/ai05-0101-1.txt

Differences between 1.2 and version 1.3
Log of other versions for file ai05s/ai05-0101-1.txt

--- ai05s/ai05-0101-1.txt	2008/10/18 02:53:57	1.2
+++ ai05s/ai05-0101-1.txt	2008/10/24 00:37:23	1.3
@@ -1,4 +1,4 @@
-!standard E.2.2(14/2)                                  08-09-24  AI05-0101-1/02
+!standard E.2.2(14/2)                                  08-10-23  AI05-0101-1/03
 !standard E.2.3(14/2)
 !class binding interpretation 08-05-28
 !status work item 08-05-28
@@ -23,13 +23,13 @@
 
 E.2.2(14/2) specifies restrictions applying to the types of non-controlling
 formals of the primitive operations of the limited private type associated
-with an RACW. The same restrictions must be applied to a non-controlling
+with an RACW. Should the same restrictions be applied to a non-controlling
 result, to ensure that the returned value can be sent back to the
-calling partition.
+calling partition? (Yes.)
 
 E.2.3(14/2) has similar language for RCI subprograms and RAS types.
-This clause should be augmented to forbid functions returning a type that
-does not support external streaming.
+Should this clause be augmented to forbid functions returning a type that
+does not support external streaming? (Yes.)
 
 !wording
 
@@ -62,6 +62,12 @@
 [Editor's note: I intend to delete the access parameter portion above as
 it is redundant and including it complicates the wording for little value.]
 
+Change E.4(7) as follows:
+
+[A] {Remote types library units (see E.2.2) and} remote call interface library unit{s}
+(see E.2.3) define[s] the remote subprograms or remote access types used for 
+remote subprogram calls.
+
 !discussion
 
 Annex E provides adequate rules describing the restrictions for parameters
@@ -129,7 +135,14 @@
 value of a remote access-to-class-wide type from another partition and return 
 that value to the caller.
 
+The change to E.4(7) is somewhat unrelated but is needed because the existing
+wording conflicts with other wording already in the standard (E.2.2 (9/3)).
+E.4(7) says that only remote call interface library units can be used to define
+remote subprogram calls, but remote types library units also define remote 
+subprogram calls and remote access types for issuing remote subprogram calls.
 
+An example, showing the usage of functions that return remote access types;
+
 package P is
    pragma Remote_Types;
 
@@ -287,6 +300,148 @@
 ... and can't support external streaming. Which is why I mentioned we
 might need a separate rule explicitly making it compulsory to convert
 such a controlling access result to an RACW.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Wednesday, October 15, 2008 10:36 AM	
+
+There seems to be a discrepency in the RM with regards to the types of
+library units that can have remote access types.
+
+E.4 (7) "A remote call interface library unit (see E.2.3) defines the
+remote subprograms or remote access types used for remote subprogram calls"
+
+E.2.2 (9/3) "A named access type declared in the visible part of a remote
+types or remote call interface library unit is called a remote access type."
+
+E.4 Says that only remote call interface library units can have remote
+access types, while E.2.2 says that both remote call interface library units
+and remote types library units can have remote access types.
+
+It seems to me that E.4 (7) should be corrected to also include remote types
+library units.
+
+Ideally this would have been caught and corrected in AI05-0060, but I
+believe it is too late to make more changes to that AI. I also had considered
+whether this could be corrected in AI05-0101, but this seems to be too
+unrelated to the subject of that AI. 
+
+I am thinking it would take a new AI to make this change. Should a new AI
+be created, or should I try to get this in to AI05-0101?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, October 15, 2008  5:10 PM	
+
+> It seems to me that E.4 (7) should be corrected to also include remote 
+> types library units.
+
+I suppose, or one could simply delete the statement (it really ought
+to be a note, not normative semantics). This is just introductory text
+and it generally doesn't have any semantic meaning. It probably should be
+marked as redundant (it is not),  as it doesn't seem to express any new
+semantics.
+
+> Ideally this would have been caught and corrected in AI05-0060, but I 
+> believe it is too late to make more changes to that AI.
+
+That is correct.
+
+> I also had considered whether this could be corrected in AI05-0101, 
+> but this seems to be too unrelated to the subject of that AI.
+
+I don't see why. It's subject is really "Things we f***ed up in AI05-0060-1".
+We often sneak in other minor changes into bigger AIs.
+ 
+> I am thinking it would take a new AI to make this change. 
+
+Please don't. We really don't need hundreds of trivial AIs to manage -- Adam
+forces us to make a lot of them as it is.
+
+> Should a new AI be created, or should I try to get this in to AI05-0101?
+
+Either that, or treat it as an editorial change and have me stick it into
+the presentation AI. Whether that is a good idea depends on whether you think
+E.4(7) has any semantic content [the original authors seem to have thought so]
+-- if it does, it shouldn't be in a presentation AI.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Wednesday, October 15, 2008 10:00 PM	
+
+> I suppose, or one could simply delete the statement (it really ought to be a
+> note, not normative semantics). This is just introductory text and it
+> generally doesn't have any semantic meaning. It probably should be marked as
+> redundant (it is not),  as it doesn't seem to express any new semantics.
+
+My argument against simply deleting the statement is that one shouldn't have to read
+section E.2.2, (entitled Remote Types Library Units) to find out something
+that pertains to Remote Call Interface Library Units. Having the statement in
+section E.4 (entitled Remote Subprogram Calls) at least puts the information in
+a place where one might look. Alternatively, a new statement could be added
+to section E.2.3 that pertains to Remote Call Interface Library units, but I would
+think it is better to minimize the changes,
+which is why I suggest we simply modify E.4 (7) to say something like;
+ 
+"[A] {Remote types library units (see E.2.2) and} remote call interface library unit{s}
+ (see E.2.3) define[s] the remote subprograms or remote access types used for 
+remote subprogram calls."
+ 
+I agree that the statement should be marked as redundant, and possibly converted into a note.
+This sounds like something that could be left for Portland and sorted out then, although I
+can resubmit AI05-0101 with this wording if you like.
+ 
+>> I also had considered whether this could be
+>> corrected in AI05-0101, but this seems to be too unrelated to
+>> the subject of that AI.
+>
+> I don't see why. It's subject is really "Things we f***ed up in
+> AI05-0060-1". 
+ 
+To be fair, I have come to the conclusion that AI05-0060 did not break anything.
+The wording affected by AI05-0101 and the wording in E.4(7) were broken long
+before AI05-0060. I believe you'd have to go farther back in time to find when
+wording changes might have been introduced that would have broken the wording for
+these sentences, if in fact they they ever did read correctly.
+AI05-0060 only improved things by plugging some of the holes and providing
+clarification. Unfortunately at the time, we weren't aware of the other bugs
+lurking in the wording related to the distributed systems annex, though it would
+have been nice to have caught them when we were working on AI05-0060. 
+ 
+>> Should a new AI be created, or should I try to get this in to AI05-0101?
+
+> Either that, or treat it as an editorial change and have me stick it into
+> the presentation AI. Whether that is a good idea depends on whether you
+> think E.4(7) has any semantic content [the original authors seem to have
+> thought so] -- if it does, it shouldn't be in a presentation AI.
+
+I suspect that E.4(7) is probably only there because it covers remote call
+interface library units in a logical place. I also note that E.4(7) is older
+wording than E.2.2(9/3). Could it be that E.4(7) once was the place
+that had the semantic content, but it was later added to E.2.2(9/3)? 
+In any case, I see this as redundant to E.2.2(9/3), but provides a better
+semantic linkage to the information pertaining for remote call interface
+library units. It's sort of a grey area whether this constitutes any
+semantic meaning, and since there is already an open AI in that has specific
+focus on the distributed systems annex, I am thinking it probably makes more
+sense to include in AI05-0101.
+ 
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, October 16, 2008  1:29 PM	
+
+>  I agree that the statement should be marked as redundant, and
+>  possibly converted into a note.
+>  This sounds like something that could be left for Portland and
+>  sorted out then, although I
+>  can resubmit AI05-0101 with this wording if you like.
+
+Yes, please do that. Otherwise, we're likely to forget to consider it at the
+meeting.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent