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

Differences between 1.8 and version 1.9
Log of other versions for file ai12s/ai12-0020-1.txt

--- ai12s/ai12-0020-1.txt	2018/06/07 00:51:47	1.8
+++ ai12s/ai12-0020-1.txt	2018/06/12 05:28:46	1.9
@@ -1948,3 +1948,260 @@
 every other day! ;-)
 
 ***************************************************************
+
+From: Steve Baird
+Sent: Wednesday, June 6, 2018  8:05 PM
+
+>> Here is a first attempt at !wording for this AI.
+> 
+> For the record, here's a few editorial-ish things that I did when 
+> posting
+> this:
+
+Thanks. It all sounds good.
+
+> ===================================
+> 
+> And here are a few minor comments:
+> 
+> (C1)
+>           except that if the value of T'Max_Image_Elements (see below)
+>           is not -1 then the variable Local_Stream is instead declared as
+>                Local_Stream : aliased
+>                  Ada.Streams.Counted_Streams.Unbounded.Unbounded_Stream
+>                    (Max_Elements => T'Max_Image_Elements);
+> 
+> Isn't this case supposed to use the Bounded form of the stream? The 
+> Unbounded form doesn't even have a discriminant. I'd guess that "Un" 
+> should be deleted from the above text (twice).
+> 
+
+Good catch. Your fix is indeed what I intended.
+
+> (C2)
+>      Pragma Default_Max_Image_Elements is a configuration pragma which
+>      takes a single argument, a static expression of type
+>      Ada.Streams.Stream_Offset in the range
+>      -1 .. Ada.Streams.Stream_Element_Offset'Last.
+>      Pragma Default_Max_Image_Elements shall not be used other than
+>      as a configuration pragma. If more than one Default_Max_Image_Elements
+>      pragma applies to a given compilation unit, then they shall all
+>      specify equal (static) Stream_Element_Offset values.
+> 
+> I'm not sure that we can use such a short definition of a pragma. All 
+> pragmas that I can think of give a syntax definition; even List and 
+> Page do that. So I think we need to define the "form" of this pragma, 
+> with a Syntax portion. (Ugh, I know.)
+
+Really? I guess I can't argue that this one is even simpler than pragma Page,
+so ok.
+
+> (C3) You probably ought to add a paragraph to the discussion 
+> describing the model and use of Bounded_Stream. I know why it's there 
+> ('cause you told me), but it doesn't seem to be mentioned anywhere in the AI.
+
+It's there for the same reason that we provide the bounded containers.
+
+> (C4) You deleted all of the AARM notes along with the original 
+> definition of Wide_Wide_Image, but you didn't put them back into the 
+> discussion of the default images of the various types. That seems like 
+> (relatively) important information about topics like Negative Zeros and 
+> rounding is getting lost.
+> The Impldef information for Wide_Image and Image definitely has to 
+> move (so the annex M.1 listing doesn't lose them). A similar thought 
+> applies to 55.b/5.
+
+Good point.
+
+> (C5) Under the image of arrays, you have:
+> 
+>     This might generate an image such as
+>         "( 1 => ( 1 => ( 123 => True,  124 => False),  2 => ( 123 => 
+> False,
+> 124 => False)),  2 => ( 1 => ( 123 => True,  124 => True),  2 => ( 123 
+> => True,  124 => False)))"
+> 
+> This is too long for a line in the RM. It will get folded somehow, and 
+> that would probably give an incorrect interpretation of the actual 
+> result. (I see this e-mail editor folded it!) I don't know what the 
+> appropriate answer is here, but this can't be in the RM as written; we 
+> need an alternative that fits in one line or additional wording to explain
+> the extra line breaks.
+
+Like you, I'm not sure what to do here. Some thought is required.
+
+> (C6)
+> 
+> For a prefix X that denotes an object of a non-universal type T, the 
+> following attributes are defined:
+> 
+> This is wrong, unless you mean to disallow using 'Image on a universal 
+> integer object. And if you meant to do that, you need to explain why 
+> and explain the (significant) incompatibility in the !discussion section.
+> Moreover, you've reintroduced the object bug fixed in AI12-0225-1. We 
+> don't want X to have to denote an object!
+> 
+> Otherwise, this should read:
+> 
+> For a prefix X of a type other than universal_real or universal_fixed, 
+> the following attributes are defined:
+
+Sounds good.
+
+> Perhaps you need to make a similar change to Put_Image; there's no 
+> problem defining it for the (dynamic) universal_integer type (that is 
+> the largest signed integer type). You can't *redefine* that attribute, 
+> but that shouldn't matter.
+
+Yes, both occurrences of "non-universal" in the wording I proposed should be
+similarly updated as you suggest.
+
+> (C7) We've previously discussed in passing the need for Ada to have 
+> "marshalling" streams. (Claw has had those since 1999 - we needed them 
+> to pack/unpack binary clipboard and registry contents - items that 
+> have to be read/written in a single operation.) You're actually adding 
+> them sort of by the back door. I have to wonder if they ought to have 
+> a bit more visibility and if the names are right -- these packages 
+> fulfill an important need having nothing to do with Image.
+> 
+> We have a "Clear" operation to discard the contents - that seems 
+> useful in more general usage, even if Put_Image will never need it.
+> 
+> We also had an initial size discriminant for the unbounded form. Not 
+> as sure if that's useful, or if there should be some Reserve_Capacity 
+> operation for the unbounded form. (We did it that way for the 
+> containers.)
+
+Good questions.
+
+I'd say don't make any changes along these lines in the !wording yet and we
+can hash it out when we discuss the AI.
+
+Thanks for the feedback,
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, June 7, 2018  5:12 PM
+
+...
+> > (C3) You probably ought to add a paragraph to the discussion 
+> > describing the model and use of Bounded_Stream. I know why it's 
+> > there ('cause you told me), but it doesn't seem to be mentioned 
+> > anywhere in
+the AI.
+> 
+> It's there for the same reason that we provide the bounded containers.
+
+Sure, but we need to describe that, and how to avoid the dynamic allocation
+implicit in the standard definition.
+
+Something like:
+
+We provide the Bounded_Stream package in order that 'Image can be used in 
+environments where dynamic allocation is banned. In such an environment, the
+user ought to <<do this, that, and the other - put a real description
+here>>. That forced the compiler to use Bounded_Stream rather than 
+here>>Stream to implement 'Image, <<more descriptive text>>.
+
+...
+> > (C5) Under the image of arrays, you have:
+> > 
+> >     This might generate an image such as
+> >         "( 1 => ( 1 => ( 123 => True,  124 => False),  2 =>
+> ( 123 =>
+> > False,
+> > 124 => False)),  2 => ( 1 => ( 123 => True,  124 => True),
+> 2 => ( 123
+> > => True,  124 => False)))"
+> > 
+> > This is too long for a line in the RM. It will get folded somehow, 
+> > and that would probably give an incorrect interpretation of the 
+> > actual result. (I see this e-mail editor folded it!) I don't know 
+> > what the appropriate answer is here, but this can't be in the RM as 
+> > written; we need an alternative that fits in one line or additional 
+> > wording to explain the extra line breaks.
+> > 
+> 
+> Like you, I'm not sure what to do here. Some thought is required.
+
+Given that, I'm going to leave fixing all of seven of these issues to you (I'm 
+over budget as it is). Please revise the AI with the changes (if I haven't 
+posted the corrected version yet when you get back from your trip, ask me for
+it first).
+
+...
+> > (C7) We've previously discussed in passing the need for Ada to have 
+> > "marshalling" streams. (Claw has had those since 1999 - we needed 
+> > them to pack/unpack binary clipboard and registry contents - items 
+> > that have to be read/written in a single operation.) You're actually 
+> > adding them sort of by the back door. I have to wonder if they ought 
+> > to have a bit more visibility and if the names are right -- these 
+> > packages fulfill an important need having nothing to do with Image.
+
+If we had more time, I would have suggested splitting them out and treating 
+them separately. But at this point, that probably would make more work than be
+helpful.
+
+> > We have a "Clear" operation to discard the contents - that seems 
+> > useful in more general usage, even if Put_Image will never need it.
+> > 
+> > We also had an initial size discriminant for the unbounded form. Not 
+> > as sure if that's useful, or if there should be some 
+> > Reserve_Capacity operation for the unbounded form. (We did it that 
+> > way for the
+> > containers.)
+> 
+> Good questions.
+> 
+> I'd say don't make any changes along these lines in the !wording yet 
+> and we can hash it out when we discuss the AI.
+
+Yes, this is fine. I just wanted to raise the issue as these packages are 
+generally useful beyond just implementing Put_Image. We ought to think about
+those more general uses, even if we don't end up making any changes for that.
+
+***************************************************************
+
+From: Jeff Cousins
+Sent: Monday, June 11, 2018  8:20 AM
+
+Some comments Steve:
+
+“The default implementation of S'Put_Image writes out (using 
+Wide_Wide_String'Write and or Wide_Wide_String'Output)” – maybe “and/or” or 
+just “or”?
+
+“The Max_Image_Elements attribute may be specified for any type type T either
+via an attribute_definition_clause, via an and aspect_specification specifying
+the Put_Image” – duplicate “type” and duplicate “an”.
+
+“(for example, the image of the nongraphic character identified as nul is
+“NUL” — the quotes are not part of the image).
+
+For a floating point type, the image written out is a decimal real
+literal best approximating the value (rounded away from zero if
+halfway between) with a single leading character that is either a minus
+sign or a space, a single digit (that is nonzero unless the value is
+zero), a decimal point, S'Digits–1 (see 3.5.8) digits after the
+decimal point (but one if S'Digits is one), an upper case E, the sign
+of the exponent (either + or –),” – what are the – meant to be?
+
+“This might generate an image such as
+      "( 1 ..  3 => ( 1 ..  0 => ( 1 .. 5 => <>)))
+, where the use of "<>" (among other things) indicates that the array
+argument is a null array.” – if 248-1 is approved, we could use “null array”
+rather than “<>”.  “<>” tends to indicate “something” (even if we’re not 
+saying exactly what here) rather than “nothing”, e.g. in 214-1 “<>” 
+indicates NOT null (pointer).
+
+“For a (specific) type extension, the default implementation of T'Put_Image
+depends on whether there exists a non-interface ancestor” – I like the 
+use of English English, but I’m sure Gary would object to the hyphen.
+
+“In the case of a protected type T, a call to the default implementation
+of T'Put_Image begins only one protected (readonly) action.“ – “read-only”.
+
+Item (Item'First .. Last)'Length” (two places) – what is meant by this??
+
+*************************************************************

Questions? Ask the ACAA Technical Agent