CVS difference for ai12s/ai12-0200-1.txt

Differences between 1.4 and version 1.5
Log of other versions for file ai12s/ai12-0200-1.txt

--- ai12s/ai12-0200-1.txt	2016/11/24 02:51:56	1.4
+++ ai12s/ai12-0200-1.txt	2016/12/06 01:00:35	1.5
@@ -1,8 +1,9 @@
-!standard A(3/4)                                    16-11-23  AI12-0200-1/03
+!standard A(3/4)                                    16-12-05  AI12-0200-1/04
 !standard 13.11.4(21/3)
 !standard 13.11.4(31/3)
 !class binding interpretation 16-08-11
 !status Amendment 1-2012 16-11-09
+!status work item 16-12-05
 !status ARG Approved 9-0-1  16-10-08
 !status work item 16-08-11
 !status received 16-06-12
@@ -35,8 +36,7 @@
 
 Replace A(3/4) by:
 
-     The implementation shall ensure that each language-defined
-     subprogram is reentrant in the sense that concurrent calls on any
+     The implementation shall ensure that concurrent calls on any
      two (possibly the same) language-defined subprograms perform as
      specified, so long as all pairs of objects (one from each call)
      that are either denoted by parameters that could be passed
@@ -48,6 +48,9 @@
 Point (1) was in fact one of the purposes of AI12-0052-1, changing the wording
 to "any language-defined subprogram" rather than "the same subprogram".
 
+We've simplified the wording to remove the use of the word "reenterant", as
+that doesn't seem to add anything other than making a long paragraph longer.
+
 !corrigendum A(3/4)
 
 @drepl
@@ -57,9 +60,8 @@
 parameters that could be passed by reference or designated by parameters of
 an access type are nonoverlapping.
 @dby
-The implementation shall ensure that each language-defined subprogram
-is reentrant in the sense that concurrent calls on any two (possibly the same)
-language-defined subprograms perform as specified, so long as all pairs of
+The implementation shall ensure that concurrent calls on any two (possibly the
+same) language-defined subprograms perform as specified, so long as all pairs of
 objects (one from each call) that are either denoted by parameters that could
 be passed by reference, or are designated by parameters of an access type, are
 nonoverlapping.
@@ -200,5 +202,188 @@
 by John. But it appears that I'm outnumbered, so I'll shut up (at least until we
 have someone who can't understand it - that may be a while, since Adam isn't
 around anymore).
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Thursday, November 24, 2016  8:56 PM
+
+I was on the verge of sending a long message about this being a really bad use
+or definition for reentrancy, which then made me think about the wording some
+more. I am sure that the words can be shortened to say:
+
+The implementation shall ensure that concurrent calls on any two (possibly the
+same) language-defined subprograms perform as specified, so long as all pairs
+of objects (one from each call) that are either denoted by parameters that
+could be passed by reference, or are designated by parameters of an access
+type, are nonoverlapping.
+
+one of the old versions for reference: 
+> The implementation shall ensure that each language-defined subprogram is
+> reentrant in the sense that concurrent calls on any two (possibly the 
+> same) language-defined subprograms perform as specified, so long as 
+> all pairs of objects (one from each call) that are either denoted by 
+> parameters that could be passed by reference, or are designated by 
+> parameters of an access type, are nonoverlapping.
+
+I believe that this has very little to do with reentrancy in the first place.
+
+At the same time, I am not sure that you are not asking for too much.
+What about shared memory at the next level of reference, i.e.
+overlapping graphs. This then is supposed to work, as long as the entrances
+are disjoint? Nice, but do we want to promise that? Or are we sure that there
+are no such cases in language-defined packages ever, now and in the future?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, November 25, 2016  6:46 AM
+
+> I believe that this has very little to do with reentrancy in the first 
+> place.
+
+Getting rid of the word "reentrant" does seem like a useful change, since we
+have argued about the meaning of "reentrant" but in fact that isn't
+particularly relevant to what we are trying to guarantee.
+
+> At the same time, I am not sure that you are not asking for too much.
+> What about shared memory at the next level of reference, i.e.
+> overlapping graphs. This then is supposed to work, as long as the
+> entrances are disjoint? Nice, but do we want to promise that? Or are we
+> sure that there are no such cases in language-defined packages ever, now
+> and in the future?
+
+Once you get to the second level, we can't make general statements any more,
+so perhaps we need to say "unless specified otherwise for a particular
+language-defined subprogram" or some such thing, though of course that makes
+the sentence even longer!
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Sunday, November 27, 2016  4:32 PM
+
+> Once you get to the second level, we can't make general statements any 
+> more, so perhaps we need to say "unless specified otherwise for a 
+> particular language-defined subprogram" or some such thing, though of 
+> course that makes the sentence even longer!
+
+Well, it is the globals of these subprograms, too. So, if any predefined
+package has state, that state is to be thread-safe by definition? The
+sentence seems to say so.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, November 27, 2016  6:31 PM
+
+> Well, it is the globals of these subprograms, too. So, if any 
+> predefined package has state, that state is to be thread-safe by 
+> definition? The sentence seems to say so.
+
+Yes, I agree that is the intent.  Local state should not be a concern of the
+user of a language-defined package, except for the special cases of Standard
+Input/Output/Error which are implicitly referenced by certain Text I/O ops.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 28, 2016  12:29 AM
+
+That's not really in question, since we discussed this extensively in
+AI12-0052-1 and then added a Ramification (A (3.b.1/4)) which states as much.
+I hate rehashing decided topics...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 28, 2016  12:40 AM
+
+>...
+> At the same time, I am not sure that you are not asking for too much.
+> What about shared memory at the next level of reference, i.e.
+> overlapping graphs. This then is supposed to work, as long as  the 
+> entrances are disjoint? Nice, but do we want to promise  that?
+
+Yes, I don't think we have a choice. A programmer can avoid top-level
+overlapping objects, but they have no way to look inside of the
+implementation of the objects. (Nor should they be dependent on such
+implementation choices.) So implementations have to guarantee that and users
+of the predefined libraries should be able to depend on it. (I would say that
+implementations need to avoid second-level stuff that might be conflicting.)
+
+That is precisely how task-safety in Claw works -- we intended to follow the
+same rules as for the predefined library (they seemed to be the best trade-off
+of performance and safety). And second-level overlaps are locked as needed
+(that's how one passes a Claw object to a task - the task makes a clone of the
+original object which then can be used safely in the task). In general, we try
+to avoid such overlaps in order to avoid the need for locking overhead.
+
+I certainly think the same is the case for the language-defined packages.
+Else the A(3) rule would be worthless; one could never portably use any
+language-defined library such that it might be accessed by multiple tasks
+(there always might be some second-level item that isn't task safe).
+
+If there is some example where we really think that causes a hardship, we can
+consider making a special exception (as we did for Text_IO and global state).
+But the general case has to be task-safety so long as the A(3) rule is
+satisfied (no obvious overlap).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 28, 2016  5:08 PM
+
+> > I believe that this has very little to do with reentrancy in the 
+> > first place.
+> 
+> Getting rid of the word "reentrant" does seem like a useful change, 
+> since we have argued about the meaning of "reentrant"
+> but in fact that isn't particularly relevant to what we are trying to 
+> guarantee.
+
+I don't feel strongly about this either way, but it does seem like more than
+an editorial change to me. Thus I think that we'll have to take a letter ballot
+on this newly proposed wording. (Since our next meeting isn't until June, we
+have plenty of time to do that and hopefully we don't have to use meeting time
+to discuss this topic again.)
+
+Before I do that, I'd like to hear from more than two ARG members. In
+particular, does anyone object to this change?
+
+****************************************************************
+
+From: Tullio Vardanega
+Sent: Tuesday, November 29, 2016  12:10 AM
+
+Erhard's cut at the sentence works for me.
+
+I am not sure I want to argue whether this has little or more to do with
+reentrancy, but the sentence can surely do without the word reentrant.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Tuesday, November 29, 2016  1:40 AM
+
+So is Erhard's proposal (of the several) the one on the table? It's ok with
+me, getting rid of the word reentrant seems a good thing.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, November 29, 2016  2:11 PM
+
+I treated the Jeff/John proposal as an editorial correction that everyone
+seemed to be happy with, and closed this topic.
+
+Erhard then reopened it with his proposal to remove a significant amount of
+the text. Since no one has opposed it yet, it seems that it ought to be
+pursued (less text is usually preferable).
+
+That's significant enough of a change that I think it has to be formally
+approved by the whole group. If such approval failed, we'd revert to the
+editorial changes only most likely (but we'd have to discuss that at a
+meeting).
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent