CVS difference for ai05s/ai05-0262-1.txt
--- ai05s/ai05-0262-1.txt 2011/10/21 06:42:22 1.4
+++ ai05s/ai05-0262-1.txt 2011/11/01 05:31:38 1.5
@@ -1,4 +1,4 @@
-!standard 1.1.2(23) 11-10-11 AI05-0262-1/03
+!standard 1.1.2(23) 11-10-26 AI05-0262-1/04
!standard 3.1(1)
!standard 3.2.4(0)
!standard 3.3(19)
@@ -28,6 +28,7 @@
!standard 7.5(2.1/2)
!standard 7.6.1(13.1/2)
!standard 7.6.1(20)
+!standard 9.10(7)
!standard 10.1.1(12.2/2)
!standard 10.1.1(12.3/2)
!standard 10.1.2(21/2)
@@ -35,25 +36,31 @@
!standard 13.11(21)
!standard 13.11.2(16)
!standard 13.11.3(4)
+!standard A.4.5(82.1/2)
!standard A.4.11(0)
!standard A.13(14)
!standard A.16(104/2)
+!standard A.16(110/2)
!standard A.16(112/2)
!standard A.18.1(7/2)
+!standard A.18.2(88/2)
!standard A.18.2(147/2)
!standard A.18.2(231/2)
!standard A.18.2(251/2)
-!standard A.18.2(252/2)
+!standard A.18.2(254/2)
+!standard A.18.3(60/2)
!standard A.18.3(88/2)
!standard A.18.3(102/2)
!standard A.18.3(145/2)
!standard A.18.3(156/2)
!standard A.18.3(159/2)
-!standard A.18.4(43/3)
+!standard A.18.4(19/2)
+!standard A.18.4(43/2)
!standard A.18.4(79/2)
!standard A.18.4(82/2)
!standard A.18.6(58/2)
!standard A.18.6(74/2)
+!standard A.18.7(18/2)
!standard A.18.7(38/2)
!standard A.18.7(100/2)
!standard A.18.7(103/2)
@@ -67,6 +74,7 @@
!standard A.18.30(0)
!standard B.2(10.1/2)
!standard B.3(2/2)
+!standard C.7.1(14)
!standard D.2.2(3.5/2)
!standard D.2.2(6.2/2)
!standard D.7(19.1/2)
@@ -281,7 +289,8 @@
Modify 6.1.1(29/3):
-"...subprogram {or entry}."
+"...subprogram {or entry}. {An exception raised by the evaluation of a precondition
+or postcondition expression is also raised at the point of call.}"
Modify 6.1.1(30/3):
"... the checks that are performed [that]{to} verify ..."
@@ -304,7 +313,7 @@
"...[may]{need} not..." ["May not" is not allowed by ISO drafting rules - ED].
-Replace the last sentence of 6.2(3/3) with: ""A parameter of a by-copy type is passed by copy, unless the
+Replace the last sentence of 6.2(3/3) with: "A parameter of a by-copy type is passed by copy, unless the
formal parameter is explicitly aliased."
Add "and" to the end of 6.3.1(16.1/3).
@@ -338,6 +347,7 @@
Modify 7.6.1(20.2/3):
"...instead of {at} the first freezing point..."
+Modify 9.10(7): "...accept_statement[.]{;}"
Modify 10.1.1(12.2/3) and 10.1.1(12.3/3): "...{immediately within}[directly in]..."
@@ -361,6 +371,7 @@
where the prefix object has been deallocated, or the case of a renaming of an entry or protected
subprogram where the associated task or protected object has been deallocated."
+Modify A.4.5(82.1/2): "...[routines]{subprograms}..."
Modify A.4.11(46/3):
@@ -370,21 +381,41 @@
Modify A.4.11(48/3): "...BOM-16LE{,} and..."
+Replace A.4.11(49/3-50/3) with:
+
+Each of the Convert and Encode functions returns a UTF_String (respectively
+UTF_8_String and UTF_16_String) value whose characters have position values
+that correspond to the encoding of the Item parameter according to the
+encoding scheme required by the function or specified by its Output_Scheme
+parameter. For UTF_8, no overlong encoding is returned. A BOM is included
+at the start of the returned string if the Output_BOM parameter is set to
+True. The lower bound of the returned string is 1.
+
+Each of the Encode functions takes a String, Wide_String, or Wide_Wide_String
+Item parameter that is assumed to be an array of unencoded characters. Each of
+the Convert functions takes a UTF_String (respectively UTF_8_String and UTF_16_String)
+Item parameter that is assumed to contain characters whose position values correspond
+to a valid encoding sequence according to the encoding scheme
+required by the function or specified by its Input_Scheme parameter.
+
+Each of the Decode functions takes a UTF_String (respectively UTF_8_String
+and UTF_16_String) Item parameter which is assumed to contain characters
+whose position values correspond to a valid encoding sequence according to
+the encoding scheme required by the function or specified by its Input_Scheme
+parameter, and returns the corresponding String, Wide_String, or value.
+The lower bound of the returned string is 1.
+
+For each of the Convert and Decode functions, an initial BOM in the input that
+matches the expected encoding scheme is ignored, and a different initial BOM
+causes Encoding_Error to be propagated.
+
Modify A.4.11(54/3 and 55/3):
"...code[-]{ }point..."
Modify A.4.11(56/3): "... In particular{,} the characters ..."
-
-Modify A.4.11(58/3): "... [which]{that} ...".
-
-Add after A.4.11(58/3):
- Each of the Encode functions takes a String, Wide_String, or Wide_Wide_String Item parameter that
- is assumed to be an array of unencoded characters. Each of the Convert functions takes a UTF_String
- (respectively UTF_8_String and UTF_16_String) Item parameter that is assumed to contain characters
- whose position values correspond to a valid encoding sequence according to the encoding scheme
- required by the function or specified by its Input_Scheme parameter.
+Delete A.4.11(57/3-58/3) [these were moved above].
Modify A.4.11(72/3, 84/3, 96/3): "... UTF-16LE{,} ..."
@@ -420,10 +451,20 @@
Modify the first sentence of A.16(104/3, 112/3): "... matching Pattern {and Filter}. ..."
+Modify A.16(110/2): "...[routine]{subprogram}..."
+
Add after A.18.1(7/2):
"Capacity_Error is raised when the capacity of a container is exceeded."
+Replace A.18.2(88.1/3), A.18.3(60.1/3), A.18.4(19.1/3), A.18.7(18.1/3),
+and A.18.10(78/3) with: [replacing "set" by the name of the container]
+
+"Set'Write writes exactly Length(Set) elements of the set to the stream. It may
+write additional information about the set as well. Set'Read reads exactly
+Length(Set) elements of Set from the stream and consumes any additional
+information written by Set'Write."
+
Modify A.18.2(147.20/3): "...setting [Target's] {the} length {of Target} to be that of Source)."
Modify A.18.2(231/3), A.18.3(145/3), A.18.26(5/3), A.18.26(9/3): "... [How many]{The number of} times..."
@@ -431,7 +472,7 @@
Modify A.18.2(251/2), A.18.3(156/2), A.18.4(79/2), A.18.7(100/2): "...that [contains]{previously
contained} the ..."
-Modify A.18.2(252/2), A.18.3(159/2), A.18.4(82/2), A.18.7(103/2):
+Modify A.18.2(254/2), A.18.3(159/2), A.18.4(82/2), A.18.7(103/2):
"..object{ and changing the length of the target object to the length of the source object}."
Modify A.18.3(88/3), A.18.4(43/3), A.18.7(38/3): "... Otherwise, {the operation is} equivalent..."
@@ -501,6 +542,12 @@
Modify B.3(2/2): "...types, constants{,} and ..."
+Modify C.7.1(14):
+
+"... Use of this attribute is allowed only inside an [entry_body or]
+accept_statement {or entry_body (after the entry_barrier)}
+corresponding to the entry_declaration denoted by E."
+
Modify D.2.2(3.5/2): "...one or more Priority_Specific_Dispatching pragmas{,} the
dispatching policy..."
@@ -523,6 +570,10 @@
wording is dubious. The formal definition in 6.1.1(18/3) is correct, but too wordy to use
in this introductory text.
+6.1.1(29/3): All exceptions that could be raised from the evaluation of a pre- or
+postcondition should be raised at the point of the call. It's best to say that, since the
+expressions could be evaluated inside the body.
+
6.1.1(33/3): We don't want the fact that checks can be turned on or off to affect the
implementation. In the case of a dispatching call, checks made at the call site
might have a different assertion policy than checks made in the subprogram body
@@ -548,6 +599,10 @@
the parameter and/or result; all of the other rules are given in the blanket paragraphs at
the start. Thus we want these are simple as possible.
+A.18.2(88/2) and similar: An unfriendly reading of this text could lead one to believe that ONLY
+elements can be written to the stream, and not additional information about empty elements,
+ordering, hashing, keys, and so on. Thus we rewrite it.
+
A.18.2(252/2), A.18.3(159/2), A.18.4(82/2), A.18.7(103/2), A.18.10(228/3): An unfriendly reading
of this text could cause one to imagine that the Length of the target is unchanged (if long
enough). So we added some additional wording to ensure that no one thinks that.
@@ -558,8 +613,6 @@
ought to be a empty container (it is always allowed to ask to delete more nodes than are
present).
-
-
A.18.6(58/2) and A.18.9(81/2): These are the defining occurrences; only ordered forms have
"predecessors".
@@ -574,6 +627,10 @@
clauses. It should apply to the whole Annex, because clearly we don't want people supporting,
say, the Export aspect in some bizarre way for a foreign language.
+C.7.1(14): A barrier should get the same result for any caller (presuming the
+same family index); that isn't likely to be true of 'Caller is included.
+Note that no compilers tested allowed E'Caller in a barrier; it is only the
+wording that seems to allow it.
!corrigendum 1.1.2(23)
@@ -708,7 +765,7 @@
belongs to a given subtype or range, or has a tag that identifies a type that is
covered by a given type. Membership tests are allowed for all types.
@dby
-A membership test, using in or not in, determines whether or
+A @i<membership test>, using @b<in> or @b<not in>, determines whether or
not a value belongs to any given subtype or range, is equal to any given value, has
a tag that identifies a type that is covered by a given type, or is convertible
to and with accessibility level appropriate for a given access type.
@@ -955,6 +1012,16 @@
of at the first freezing point of the access type.
+!corrigendum 9.10(7)
+
+@drepl
+@xbullet<If A1 is the action of issuing an entry call, and A2 is part of the corresponding
+execution of the appropriate @fa<entry_body> or @fa<accept_statement>.>
+@dby
+@xbullet<If A1 is the action of issuing an entry call, and A2 is part of the corresponding
+execution of the appropriate @fa<entry_body> or @fa<accept_statement>;>
+
+
!corrigendum 10.1.1(12.2/2)
@drepl
@@ -1060,6 +1127,22 @@
another @fa<pragma> Default_Storage_Pool.
+!corrigendum A.4.5(82.1/2)
+
+@drepl
+The function Unbounded_Slice returns the slice at positions Low through High in the
+string represented by Source as an Unbounded_String. The procedure Unbounded_Slice
+sets Target to the Unbounded_String representing the slice at positions Low through
+High in the string represented by Source. Both routines propagate Index_Error if
+Low > Length(Source)+1 or High > Length(Source).
+@dby
+The function Unbounded_Slice returns the slice at positions Low through High in the
+string represented by Source as an Unbounded_String. The procedure Unbounded_Slice
+sets Target to the Unbounded_String representing the slice at positions Low through
+High in the string represented by Source. Both subprograms propagate Index_Error if
+Low > Length(Source)+1 or High > Length(Source).
+
+
!corrigendum A.4.11(0)
@dinsc
@@ -1112,6 +1195,25 @@
given name (in the absence of Name_Error). When Start_Search propagates
Name_Error or Use_Error, the object Search will have no entries available.>
+!corrigendum A.16(110/2)
+
+@drepl
+@xindent<Returns the next Directory_Entry for the search described by Search that
+matches the pattern and filter. If no further matches are available, Status_Error
+is raised. It is implementation-defined as to whether the results returned by this
+routine are altered if the contents of the directory are altered while the Search
+object is valid (for example, by another program). The exception Use_Error is
+propagated if the external environment does not support continued searching of the
+directory represented by Search.>
+@dby
+@xindent<Returns the next Directory_Entry for the search described by Search that
+matches the pattern and filter. If no further matches are available, Status_Error
+is raised. It is implementation-defined as to whether the results returned by this
+subprogram are altered if the contents of the directory are altered while the Search
+object is valid (for example, by another program). The exception Use_Error is
+propagated if the external environment does not support continued searching of the
+directory represented by Search.>
+
!corrigendum A.16(112/2)
@drepl
@@ -1147,6 +1249,17 @@
@dby
Capacity_Error is raised when the capacity of a container is exceeded.
+!corrigendum A.18.2(88/2)
+
+@dinsa
+Execution of the default implementation of the Input, Output, Read, or Write
+attribute of type Cursor raises Program_Error.
+@dinst
+Vector'Write writes exactly Length(Vector) elements of the vector to the stream.
+It may write additional information about the vector as well. Vector'Read reads
+exactly Length(Vector) elements of Vector from the stream and consumes any
+additional information written by Vector'Write.
+
!corrigendum A.18.2(147/2)
@dinsa
@@ -1181,7 +1294,7 @@
@xbullet<The element it designates has been deleted or removed from the vector
that previously contained the element.>
-!corrigendum A.18.2(252/2)
+!corrigendum A.18.2(254/2)
@drepl
The execution of an @fa<assignment_statement> for a vector shall have the effect of
@@ -1191,6 +1304,17 @@
copying the elements from the source vector object to the target vector object
and changing the length of the target object to that of the source object.
+!corrigendum A.18.3(60/2)
+
+@dinsa
+Execution of the default implementation of the Input, Output, Read, or Write attribute of
+type Cursor raises Program_Error.
+@dinst
+List'Write writes exactly Length(List) elements of the list to the stream. It
+may write additional information about the list as well. List'Read reads exactly
+Length(List) elements of List from the stream and consumes any additional
+information written by List'Write.
+
!corrigendum A.18.3(88/2)
@drepl
@@ -1247,6 +1371,17 @@
copying the elements from the source list object to the target list object
and changing the length of the target object to that of the source object.
+!corrigendum A.18.4(19/2)
+
+@dinsa
+Execution of the default implementation of the Input, Output, Read, or Write
+attribute of type Cursor raises Program_Error.
+@dinst
+Map'Write writes exactly Length(Map) elements of the map to the stream. It may
+write additional information about the map as well. Map'Read reads exactly
+Length(Map) elements of Map from the stream and consumes any additional
+information written by Map'Write.
+
!corrigendum A.18.4(43/2)
@drepl
@@ -1305,6 +1440,21 @@
returns a cursor designating the predecessor node of the one designated by Position.
If Position designates the first element, then Previous returns No_Element.
+!corrigendum A.18.7(18/2)
+!AI-0001-1
+!AI-0212-1
+!AI-0262-1
+
+@dinsa
+Execution of the default implementation of the Input, Output, Read, or Write
+attribute of type Cursor raises Program_Error.
+@dinst
+Set'Write writes exactly Length(Set) elements of the set to the stream. It may
+write additional information about the set as well. Set'Read reads exactly
+Length(Set) elements of Set from the stream and consumes any additional
+information written by Set'Write.
+
+
!corrigendum A.18.7(100/2)
@drepl
@@ -1448,6 +1598,22 @@
When this clause mentions a C entity, the reference also applies to the
corresponding entity in C++.
+!corrigendum C.7.1(14)
+
+@drepl
+@xhang<@xterm<E'Caller>
+Yields a value of the type Task_Id that identifies the task whose call is now
+being serviced. Use of this attribute is allowed only inside an @fa<entry_body>
+or @fa<accept_statement> corresponding to the @fa<entry_declaration> denoted by
+E.>
+@dby
+@xhang<@xterm<E'Caller>
+Yields a value of the type Task_Id that identifies the task whose call is now
+being serviced. Use of this attribute is allowed only inside an
+@fa<accept_statement> or @fa<entry_body> (after the @fa<entry_barrier>)
+corresponding to the @fa<entry_declaration> denoted by E.>
+
+
!corrigendum D.2.2(3.5/2)
@drepl
@@ -2016,7 +2182,110 @@
****************************************************************
+From: Tucker Taft
+Sent: Sunday, September 18, 2011 9:43 AM
+
+Not really an "editorial" comment, but I did bump into an ambiguity today when
+looking at the description of the 'Caller attribute. It says it is allowed only
+within the entry body or accept statement, but that seems to imply it might be
+allowed in the entry barrier. But that clearly wouldn't work since the same
+value of the entry barrier must be used for all callers of a given entry, so the
+entry barrier can't depend on 'Caller. So if we are in the mood for clarifying
+this section, which does have some Ada 2012 changes, we might say:
+
+E'Caller
+ Yields a value of the type Task_Id that identifies
+ the task whose call is now being serviced. Use of
+ this attribute is allowed only inside an [entry_body or]
+ accept_statement {or entry_body (after the entry_barrier)}
+ corresponding to the entry_declaration denoted by E.
+
+I moved accept_statement before entry_body because the parenthetical clause made
+the sentence harder to understand if the clause was followed by "or
+accept_statement."
+
+Certainly not a biggie, but I at least was confused by this when I read it
+today, and actually wrote a test program to see what our compiler actually did
+(it disallowed the attribute, luckily!).
+
+****************************************************************
+
+From: Tullio Vardanega
+Sent: Sunday, September 18, 2011 10:01 AM
+
+Yes, please.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, September 18, 2011 10:27 AM
+
+Interestingly, I just noticed the following in this same section:
+
+17.c/2
+ Ramification: {AI95-00237-01} An entry barrier is syntactically
+ part of an entry_body, so a call to Current_Task from an entry barrier
+ is also covered by this rule.
+
+So this makes it clear that an entry barrier *is* considered part of an
+entry_body, so paragraph (14) is no longer just ambiguous -- it is wrong.
+
+By the way, GNAT rejects use of 'Caller in an entry barrier as well, with the
+following message:
+
+ Caller must appear in matching accept or body
+
+AdaMagic rejects it with:
+
+ LRM:C.7.1(13), The use of 'CALLER must be in an entry body
+ or accept statement for the entry denoted by the prefix
+
+I have attached the test program caller2.adb
+
+----
+
+with Ada.Task_Identification;
+use Ada.Task_Identification;
+procedure caller2 is
+ protected type PT is
+ entry Test(Integer range -10 .. 10)(X : Integer);
+ private
+ Data : Integer := 0;
+ end PT;
+
+ protected body PT is
+ entry Test(for I in Integer range -10 .. 10)(X : Integer)
+ when Test'Caller /= Null_Task_Id and then I > 0 is
+ begin
+ Data := X;
+ end Test;
+ end PT;
+ PO : PT;
+begin
+ PO.Test(3)(5);
+end;
+
+****************************************************************
+
From: Randy Brukardt
+Sent: Wednesday, October 26, 2011 10:11 PM
+
+> I have attached the test program caller2.adb
+
+For what it's worth (not much :-), Janus/Ada rejects this with the not very
+useful message:
+
+*ERROR* Prefix must name a task or PT entry (6.4.1) [RM C.7.1(14)]
+
+Interestingly, it does the same in the entry body if this is an entry family (as
+in the original test program), but if the family is removed, then it allows it
+in the body but not the barrier. (All with the same almost useless message.) The
+family bit is a another bug for the pile; otherwise, the behavior matches the
+other two compilers.
+
+****************************************************************
+
+From: Randy Brukardt
Sent: Tuesday, September 27, 2011 9:58 PM
Bob has in his review:
@@ -2552,6 +2821,36 @@
****************************************************************
+From: Jean-Pierre Rosen
+Sent: Thursday, October 13, 2011 3:04 AM
+
+Rereading the section, I propose to reorganize current paragraphs 49 to
+58 as follows:
+
+Each of the Convert and Encode functions returns a UTF_String (respectively
+UTF_8_String and UTF_16_String) value whose characters have position values that
+correspond to the encoding of the Item parameter according to the encoding scheme
+required by the function or specified by its Output_Scheme parameter. For UTF_8,
+no overlong encoding is returned. A BOM is included at the start of the returned
+string if the Output_BOM parameter is set to True. The lower bound of the returned
+string is 1.
+
+Each of the Decode functions takes a UTF_String (respectively UTF_8_String and
+UTF_16_String) Item parameter which is assumed to contain characters whose
+position values correspond to a valid encoding sequence according to the encoding
+scheme required by the function or specified by its Input_Scheme parameter, and
+returns the corresponding String, Wide_String, or value. The lower bound of the
+returned string is 1.
+
+For each of the Convert and Decode functions, an initial BOM in the input that
+matches the expected encoding scheme is ignored, and a different initial BOM causes
+Encoding_Error to be propagated.
+
+The exception Encoding_Error is also propagated in the following
+situations: ...
+
+****************************************************************
+
From: Matthew Heaney
Sent: Monday, October 17, 2011 2:05 PM
@@ -2848,7 +3147,7 @@
From: Matthew Heaney
Sent: Tuesday, October 18, 2011 10:02 AM
-> This reminds me that we've already had this discussion vis-a-vis
+> This reminds me that we've already had this discussion vis-a-vis
> Delete, and I'm pretty sure that the wording in the Standard is correct.
Agreed. I just thought it was odd that Delete_First allows you to delete from
@@ -2864,5 +3163,315 @@
> I've put the above wording into the editorial review AI.
OK, thanks for looking into that.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, October 12, 2011 8:41 PM
+
+Erhard writes in one of his reviews:
+
+>A.18.7(18.1/3) reads
+>> Set'Write writes the length of Set elements to the stream. Set'Read
+>> reads the length of Set elements from the stream.
+
+>I am not into Sets, but it seems very unlikely to me that the semantics
+>should be that the 'Read and 'Write attributes would
+>
+> - not write the set itself, but (only) some length; note that only the
+> default version composes automatically. The above should probably say
+> "The default implementation of Set'Write ... to the stream prior to
+> the streaming of the
+> components. The default implementation of Set'read reads....
+>
+> - write the length of the ELEMENTS (i.e., of the next dimension down),
+> instead of the the "length" of the SET (quite a misnomer for a set size,
+> but that is old stuff).
+>
+>This comment applies to many subsections; see AI05-00001 for where they are.
+
+It looks to me that someone tried to "improve" the readability of this text, and
+turned it into hash. It is supposed to say
+
+Set'Write writes Length (Set) elements to the stream. Set'Read reads Length
+(Set) elements from the stream.
+
+the point here being that the number of elements written is Length (Set) [or
+whatever container], and not some more convinient number. In particular, it does
+*not* stream the entire Capacity of elements for a bounded form (which would be
+the "natural" implementation). There is an AARM Implementation Note under
+Vectors which explains this (A.18.2(88.b/3). It's a bit weird that there isn't a
+similar note in the other places (usually a shorter one referring to Vectors for
+details) -- we usually do that -- but in any case that note makes the intent
+clear.
+
+[Aside: We could use the prefix form Set.Length rather than the call form Length
+(Set), but reviewers have generally hated the use of the prefix form. So I'm not
+suggesting that.]
+
+But I note that this wording seems to imply that this is *all* that Set'Write
+does, and that is not the intent -- this is intended solely to specify the
+number of calls to Element'Write, and not to say anything about any other
+contents. (Other than that there is a requirement that bounded and unbounded
+containers use the same contents -- this is given in the various bounded forms.)
+So I think we need a more extensive rewording, but I'm not sure what it should
+be.
+
+The best I can come up with is:
+
+Set'Write writes exactly Length (Set) elements to the stream and may write other
+information about the Set as well. Set'Read reads exactly Length (Set) elements
+from the stream along with any other information written by Set'Write.
+
+But this seems rather wordy and vaguely over-specified. Does anyone have any
+better ideas??
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Thursday, October 13, 2011 1:04 PM
+
+My stab at it....
+
+Set'Write writes Length(Set) elements of the SET to the stream. It may write
+additional information about the Set as well. Set'Read reads Length(Set)
+elements of Set from the stream and consumes any additional information written
+by Set'Write.
+
+It's difficult to get it shorter (unless is is implicitly acceptable that Read
+and Writes generally stream hidden information as well. Then one could drop the
+second parts and put this only into the AARM.)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, October 15, 2011 10:18 PM
+
+Tucker, Bob, someone, help us out here. The problem with the original wording is
+that it appears to say that *only* elements are written to the stream, which
+isn't possible in general. (And in some versions, it also appears to say that
+only the length is written, which is balmy.)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, October 15, 2011 10:42 AM
+
+I think we want the stream representation of containers to be as portable as
+possible. What could you possibly need for a Set over and above the elements
+themselves, and some way to know when you have read all the elements?
+Furthermore, didn't we have a desire that you could read a bounded container
+having written an unbounded one, and vice-versa? Or do I misremember that?
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Saturday, October 15, 2011 11:20 AM
+
+You remember correctly, this is AI05-0184 : compatibility of streaming of
+containers.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, October 15, 2011 6:43 PM
+
+> Or do I misremember that?
+
+You're not helping. :-)
+
+First, this wording is used for all of the containers; it's not specific to
+Sets. It just happens that Erhard was reviewing the sets when this came up.
+
+One could imagine that for Sets and Lists, that you would require the streaming
+to be a length following by the elements. But that doesn't make sense for the
+other containers. (And it's not a great idea even for the sets, see below.)
+
+* For vectors, we have to handle "empty elements". In the case the indefinite
+ forms, "empty elements" probably don't exist at all and cannot be streamed. So
+ there has to be an empty vs. non-empty bit in the stream for each element. And
+ I don't think we want to prevent definite containers from having and streaming
+ such a bit (although it is not required to have such a bit). Janus/Ada will
+ have a empty element bit for the definite containers - it's safer than
+ ignoring the error.
+
+* For maps, we clearly need to stream the keys in some way.
+
+* For trees, we have to stream the relationship of the elements in some way.
+ Else the stream would lose the structure, which would be bad news.
+
+* For hashed maps and sets, we ought to allow streaming some form of the hash
+ table. Requiring the hash table to be rebuilt on a read could be quite
+ expensive (every element would have to be hashed), especially with large
+ containers and a slow hash function.
+
+* For ordered maps and sets, it might make sense to stream some indication of
+ the red/black tree structure. Again, it might be expensive to rebuild that for
+ large containers. (I don't know enough about red-black trees to know for sure
+ on this one, and I'd hate for the language to make such a decision.)
+
+* Even for holders, we have to stream an indication of whether the holder is
+ empty or not: it's not just an element.
+
+The point is that implementations may want to stream other information to make
+recreating the structure cheaper (or possible!). I don't think the language
+should get in the way of that.
+
+The only properties that we intended to guarentee:
+
+(1) That unbounded and bounded forms of a particular container use the same
+ stream format. A.18.19(11-14/3) does this for vectors, similar wording
+ exists for all of the other containers.
+
+(2) That the stream contains only elements that are in use, not the entire
+ capacity of the container. Specifically, Length of container elements are
+ written (for containers that have lengths). That's what this text was
+ supposed to ensure. But it reads as if it means a lot more than that, which
+ is the problem.
+
+So, please suggest some improved wording -- I know you're good at it.
+
+I had again:
+
+> Set'Write writes exactly Length (Set) elements to the stream and may
+> write other information about the Set as well. Set'Read reads exactly
+> Length (Set) elements from the stream along with any other information
+> written by Set'Write.
+
+Erhard had:
+
+> Set'Write writes Length(Set) elements of the SET to the stream. It may write
+> additional information about the Set as well. Set'Read reads Length(Set)
+> elements of Set from the stream and consumes any additional information
+> written by Set'Write.
+
+P.S. Queues are limited, and thus don't have stream attributes by default, and
+none are defined. I think this is intended, but I don't think we ever discussed
+it. Should the queues have explicitly declared stream attributes??
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, October 15, 2011 7:15 PM
+
+I mildly prefer Erhard's wording.
+
+> P.S. Queues are limited, and thus don't have stream attributes by
+> default, and none are defined. I think this is intended, but I don't
+> think we ever discussed it. Should the queues have explicitly declared stream attributes??
+
+No, no need in my view. And how would it deal with concurrent changes to the
+queue? This seems like a race-condition waiting to happen.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Saturday, October 15, 2011 11:35 PM
+
+I mildly prefer a mix of Randy's and Erhards, :-) I had suggested wording for
+this in my review as well, if I mix in my version with Randy's and Erhards,
+would this be an improvement?
+
+Set'Write writes the elements of Set to the stream, and may write other
+information about the Set as well. Set'Read reads Length (Set) elements from the
+stream, along with any other information written by Set'Write.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, October 16, 2011 7:14 PM
+
+Not exactly like this, because the Write wording doesn't say how many elements
+are written, which is the entire point of the wording. (We could probably leave
+that information out of 'Read, since it has to "work", but for 'Write, anything
+would work so long as 'Read is the same.)
+
+The whole (original) point of this wording was to say that writing
+*capacity* elements (rather than length elements) is wrong. That needs to be
+fairly clear, as writing capacity elements is easier (it probably will happen
+"naturally" for bounded forms).
+
+I note that neither my wording nor Erhard's makes it crystal clear that the
+elements written are the "active" ones, but I don't think that is necessary, as
+'Read would not "work" if some other elements are written (and the right number
+is written as well).
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Monday, October 17, 2011 8:43 AM
+
+> Set'Write writes the elements of Set to the stream, and may write
+> other information about the Set as well.
+> Set'Read reads Length (Set) elements from the stream, along with any
+> other information written by Set'Write.
+
+Please a symmetric wording. If Read talks about Length(Set), Write should do,
+too. Or neither should (which would be fine by me, but others have obviously
+argued that one needs to make clear that unoccupied slots in the container for
+Set are not written).
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Monday, October 17, 2011 12:09 AM
+
+> The whole (original) point of this wording was to say that writing
+> *capacity* elements (rather than length elements) is wrong. That needs
+> to be fairly clear, as writing capacity elements is easier (it
+> probably will happen "naturally" for bounded forms).
+
+But an implementation could write capacity elements, and argue that the extra
+ones are just "service" information... Oh well, there are so many ways to make
+unfriendly implementations. But maybe, turning this sentence into IA would be
+more honest.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Sunday, October 16, 2011 7:16 AM
+
+I noticed that all descriptions of predicates are completely silent on what
+happens if any (dynamic) predicate expression raises an exception.
+
+Presumably canonical semantics apply: the exception is raised at the point where
+the predicate expression is evaluated. These points are sufficiently precisely
+described for subtype predicates and for type invariants.
+
+For preconditions (and maybe postconditions?), however, that does not seem to be
+the case, and the RM caters to it by stating for the Assertion_Error exception:
+6.1.1 29/3
+{AI05-0145-2} If a precondition or postcondition check fails, the exception is
+raised at the point of the call. [The exception cannot be handled inside the
+called subprogram.]
+
+The sentence needs to be extended to cover exceptions raised by the evaluation
+of the predicate expressions.
+
+Add a sentence to 29/3: The same applies to exceptions raised by the evaluation
+of precondition or postcondition expressions.
+
+----
+I tried to merge it into the first sentence, but ultimately I preferred the
+above version. Just in case, here is the combined version, if you prefer that.
+
+{AI05-0145-2} If the evaluation of a precondition or postcondition expression
+raises an exception, or if a failed precondition or postcondition check raises
+Assertion_Error, the exception is raised at the point of the call. [The
+exception cannot be handled inside the called subprogram.]
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, October 27, 2011 9:21 PM
+
+I understand your concern, but am not very happy with this wording. For one thing,
+there is only one exception raised, so wording that is plural is suspicious. (I
+recall some reviewer complaining about similar wording elsewhere.) And I don't
+find it clear what "The same" refers to.
+
+So I used:
+"An exception raised by the evaluation of a precondition or postcondition
+expression is also raised at the point of call."
****************************************************************
Questions? Ask the ACAA Technical Agent