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

Differences between 1.16 and version 1.17
Log of other versions for file ai12s/ai12-0003-1.txt

--- ai12s/ai12-0003-1.txt	2015/01/30 05:23:09	1.16
+++ ai12s/ai12-0003-1.txt	2015/01/31 01:45:26	1.17
@@ -66,7 +66,7 @@
    pragma. That would eliminate the need for a special check. But it would
    be bizarre to have something that could resolve to either an object or a
    (single) package, and resolving to package Standard would imply that the
-   standard pool is an object declared in that package. A storage pool object 
+   standard pool is an object declared in that package. A storage pool object
    must be a variable (see 13.11), yet preelaborable packages depend on package
    Standard, which would require implementers to implement the standard storage
    pool with Preelaborable_Initialization, which is an unnecessary restriction.
@@ -1938,7 +1938,7 @@
 
 ****************************************************************
 
-From: Randy Brukardy
+From: Randy Brukardt
 Sent: Wednesday, January 28, 2015  10:13 PM
 
 Just noticed that you didn't make a matching version of the new rule for aspect
@@ -1953,5 +1953,445 @@
 package Standard itself.
 
 You can do any wordsmithing as part of your Editorial Review.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, January 28, 2015  11:06 PM
+
+Just found another problem with this AI. The syntax change is described as:
+
+   storage_pool_indicator ::= storage_pool_name | null {| Standard}
+
+I was trying to figure out what font "Standard" should be in, and discovered
+that none of the other pragmas I checked use this sort of syntax. Rather an
+"identifier specific to a pragma" are syntactally described as "identifier"
+along with a textual rule stating which identifiers are allowed. (See pragma
+List in 2.8, pragma Suppress in 11.5 (check names), pragma Convention (now in
+J.15.5), etc.)
+
+So the syntax should be
+
+   storage_pool_indicator ::= storage_pool_name | null {| identifier}
+
+And the we have to add something like the following to 13.11.3(4/3):
+
+   If the storage_pool_indicator is an identifier, the identifier shall be
+   Standard.
+
+Or maybe in the Syntax section,
+   The only identifier that can be used in a storage_pool_indicator is Standard.
+
+But in both cases, that sounds like it's talking about the name as well as the
+identifier specific to a pragma.
+
+It would be better to put this in Static Semantics and say something similar to
+what pragma List says:
+
+A pragma Default_Storage_Pool takes the identifier Standard, the reserved word
+*null*, or the name of a storage pool as the single argument.
+
+but that would either require two static semantics sections, or a wholesale
+rearrangement of the subclause. And it repeats most of the separate syntax item.
+
+Humm...
+
+Maybe a wholesale rearrangement wouldn't be a bad idea. There's never any text
+in this clause that explains what this silly pragma is for. We don't find out
+what it does until 11 paragraphs in! And we could hang the meaning of
+"identifier" in the 13.11.3(4.2/3) wording.
+
+Paragraph 1 is unused. Maybe we should start the whole thing with something
+like:
+
+Redundant[Pragma and aspect Default_Storage_Pool specify the pool that will be
+used in the absence of an explicit specification for an access type.]
+
+Bah. This AI is getting to be like the piece of paper stuck to your shoe on the
+street. You think you've gotten rid of it, and a little while later you realize
+it is still there!!!
+
+I'm going to try this again tomorrow. I just realized that I've been doing this
+for most of the last 12 hours (our phone meeting started exactly 12 hours ago as
+I write this), and that's more than enough for one day.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, January 29, 2015  5:54 AM
+
+> Standard when used aspect_definition for the Default_Storage_Pool
+> aspect is an identifier specific to an aspect (see 13.1.1) and does
+> not denote any declaration. If the aspect_definition for the
+> Default_Storage_Pool aspect is Standard, then there shall not be a
+> declaration with defining identifier Standard that is immediately
+> visible at the point of the aspect, other than package Standard itself.
+
+I would be perfectly happy instead with simply a rule saying that if there is
+such a declaration, the Standard referenced is resolved as meaning the (context
+sensitive keyword) Standard.
+
+In practice, the above legality rule is 100.00000% useless. This case will never
+arise. All it does is make implementations waste time implementing a completely
+useless legality rule, which if it is ever triggered will only be triggered in
+an annoying(*) ACATS test.
+
+(*) I hereby declare that I use annoying as a term of art here, to mean a test
+that tests something that will never ever occur in real programs :-)
+
+In this case, the legality rule is easy to implement, so no big deal, but my
+aesthetics are sort of diametrically opposite to those of many of those on the
+ARG. To me, the legality rule makes a nasty wart in the implementation, which I
+find unaesthetic, whereas I don't have any problem at all with a rule in the
+language resolving the ambiguity. As I mentioned in a previous note, GNAT has a
+few of these anyway. So working to avoid such ambiguities in the official
+theological document, which talks about a language (strict Standard Ad) which no
+one uses, seems a bit of a waste of effort.
+
+If you DO add a rule, I would prefer it be more specific, disallowing ONLY a
+declaration of a "Standard" storage pool, and not making other perfectly
+reasonable uses of Standard illegal (and such uses could even be in a separate
+parent unit, which would be quite annoying!)
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Thursday, January 29, 2015  10:08 AM
+
+> In practice, the above legality rule is 100.00000% useless. This case
+> will never arise.
+
+Hmmm... I think that's what I suggested, but a previous incarnation of RBKD
+popped up and said that it would suddenly change the meaning of zillions of
+programs that had a visible storage pool called Standard, and that it was an
+unbearable incompatibility...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 29, 2015  6:21 PM
+
+...
+> I would be perfectly happy instead with simply a rule saying that if
+> there is such a declaration, the Standard referenced is resolved as
+> meaning the (context sensitive keyword) Standard.
+
+We of course have that - it's the definition of what "Standard" means in the
+pragma. But Tucker insisted that we go further, and we agreed to the wording I
+gave; we just forgot the aspect version. I thought you were on the call
+yesterday when we decided that??
+
+I believe Tucker's argument is that this pragma is different than the others
+with identifiers-specific-to-a-pragma, as it also allows user-defined names of
+entities. So there is a chance for confusion.
+
+> In practice, the above legality rule is 100.00000% useless.
+> This case will never arise. All it does is make implementations waste
+> time implementing a completely useless legality rule, which if it is
+> ever triggered will only be triggered in an annoying(*) ACATS test.
+>
+> (*) I hereby declare that I use annoying as a term of art here, to
+> mean a test that tests something that will never ever occur in real
+> programs :-)
+
+Yes, I know that and completely agree with you. But not everyone
+does...sometimes one has to take compromise positions to get things done. And
+this is rather unimportant in the grand scheme of things, especially as it will
+never happen.
+
+...
+> If you DO add a rule, I would prefer it be more specific, disallowing
+> ONLY a declaration of a "Standard" storage pool, and not making other
+> perfectly reasonable uses of Standard illegal (and such uses could
+> even be in a separate parent unit, which would be quite annoying!)
+
+(1) There are no "perfectly reasonable uses of Standard"! There are legal uses
+of Standard, but as we all seemed to agree, redefining non-overloadable entities
+defined in Standard and Standard itself is a bad practice. There is nothing
+"reasonable" about bad practice.
+
+(2) If you are right about "This case will never arise", then arguing about the
+exact form of the rule is pointless. Why make a rule that will never happen more
+complex? (And a lot more complex to implement.)
+
+(3) I'd argue the above is overly specific. There are a number of ways to write
+something confusing named Standard related to a storage pool, and if we're going
+to catch any of them, we ought to catch them all. Besides objects of a storage
+pool named Standard, you could have a function (parameterless or with all
+defaulted parameters). You could also have an object or function returning an
+access-to-storage-pool. That would require .all to be legal (so the exact case
+wouldn't hit), but I for one leave out .all in such contexts all of the time
+(thinking that it is implicit when in fact it isn't). I expect the compiler to
+flag such bugs, but in this case it would not (it would just do something
+different than intended).
+
+Specifically, I might write something like:
+
+       type Pools is access all Root_Storage_Pool'Class;
+
+       function The_Pool return Pools;
+
+       pragma Default_Storage_Pool (The_Pool); -- Illegal, .all is missing.
+
+But if you were to change The_Pool to Standard, the error would disappear and a
+misinterpretation would happen.
+
+So I think the simpler rule is better; it's easier to check, it covers all of
+the confusing cases without complication, and the exact rule we chose is going
+to matter to someone other than an implementer approximately 0.0% of the time.
+
+And while I'd prefer no rule at all, that last fact tells me that arguing about
+the content/absence of a rule for this particular corner is rather silly.
+Hopefully end of story.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, January 29, 2015  11:00 AM
+
+> Just found another problem with this AI. The syntax change is described as:
+>
+>    storage_pool_indicator ::= storage_pool_name | null {| Standard}
+>
+> I was trying to figure out what font "Standard" should be in, ...
+
+Really?!  Seriously, Randy, I think you've got a lot more important ways to
+spend your time.  ;-)
+
+The above syntax is crystal clear.  Put Standard in the usual font for
+identifiers in the text.
+
+This is one of the few cases in language design where "A foolish consistency is
+the hobgoblin of little minds" applies.  All of the suggestions below make it
+less clear, purely for a foolish consistency.
+
+(I don't mind adding an explanatory introductory Redundant, as you suggest.  But
+a "wholesale rearrangement" seems like a waste of your valuable time.)
+
+>...and discovered
+> that none of the other pragmas I checked use this sort of syntax.
+>Rather an  "identifier specific to a pragma" are syntactally described as "identifier"
+> along with a textual rule stating which identifiers are allowed. (See
+>pragma  List in 2.8, pragma Suppress in 11.5 (check names), pragma
+>Convention (now  in J.15.5), etc.)
+>
+> So the syntax should be
+>
+>    storage_pool_indicator ::= storage_pool_name | null {| identifier}
+
+Forcing the reader to rummage around to find out what "identifier" is allowed in
+this case is unhelpful.  The other pragmas are different, because they allow
+more than one identifier, so the apparent inconsistency doesn't bother me.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 28, 2015  6:39 PM
+
+> > Just found another problem with this AI. The syntax change
+> is described as:
+> >
+> >    storage_pool_indicator ::= storage_pool_name | null {| Standard}
+> >
+> > I was trying to figure out what font "Standard" should be in, ...
+>
+> Really?!  Seriously, Randy, I think you've got a lot more important
+> ways to spend your time.  ;-)
+
+Seriously. See below.
+
+> The above syntax is crystal clear.  Put Standard in the usual font for
+> identifiers in the text.
+>
+> This is one of the few cases in language design where "A foolish
+> consistency is the hobgoblin of little minds"
+> applies.  All of the suggestions below make it less clear, purely for
+> a foolish consistency.
+
+Sorry, an editor's primary job is enforcing consistency. I've had to spend time
+on a lot more foolish things than this. (For example, making sure that
+"nonabstract" is spelled without a hyphen everywhere - thanks, Gary. ;-)
+
+Secondly, the suggestions below are what happens if it is not rearranged. If we
+put the wording into the paragraph that already says that Standard is an
+identifier specific to a pragma, and hoist that, I think it will become much
+clearer. (If not, I won't do it.) The "hoisting" is a good idea anyway, as the
+proposed wording uses "Standard" for multiple paragraphs before it explains what
+it is. That should come first. I think this whole clause got inside-out somehow
+(the most important stuff comes last).
+
+Thirdly, you're probably forgotten the crazy markup of the syntax in the RM
+generator. The Ada 9x team foisted that on me (I believe it was foisted on you,
+too, so I don't blame you so much as pity you...). Since the syntax is
+automatically processed to make the Annex P tables and cross-references, and the
+automatically generated cross-links in the HTML version, what can be put into it
+is very strictly limited. For that reason, I don't ever create new RM syntax
+markup, I always find some existing rule to copy. My problem here is I couldn't
+do that.
+
+Fourthly, this grammar could work for the pragma, but it doesn't work for the
+aspect (for which there is no syntax change; as Brad points out, null is not
+allowed there so the above syntax isn't used in its wording). So I still need to
+make the wording fix for that one.
+
+> (I don't mind adding an explanatory introductory Redundant, as you
+> suggest.  But a "wholesale rearrangement" seems like a waste of your
+> valuable time.)
+
+Well, at the moment, still have a lot of my Corrigendum budget left, so it's not
+clear how valuable that time is. One never wants to have budgeted money left
+over at the end of a fiscal year. :-)
+
+Anyway, I still have to put this wording in the RM; it'll take about the same
+amount of time to rearrange it now as it would to do it later once people look
+at it in context. I think I'm spending more time answering this message than I'd
+save by not doing anything. :-)
+
+And it should be remembered that I sent the note you're replying to after 11
+hours of straight ARG work. My brain pretty much wasn't working, or I would have
+just sent a proposal and not a list of ramblings.
+
+...
+> > I'm going to try this again tomorrow. I just realized that I've been
+> > doing this for most of the last 12 hours (our phone meeting started
+> > exactly 12 hours ago as I write this), and that's more than enough
+> > for one day.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 29, 2015  7:57 PM
+
+OK, below is the RM Text for entire clause, is it will look after applying
+AI12-0003-1 and my proposed redo. This doesn't show any change marks; it's
+intended for maximum readability.
+
+Ultimately, I left the syntax for the pragma alone because I can't find any
+decent way to word the "correct" text. I hope that the syntax of "digit" can be
+copied for this purpose (there is no instance of a complete non-reserved
+identifier in the RM).
+
+My intent is that the semantics are exactly as we approved yesterday, just with
+less verbiage and no holes.
+
+I rearranged the text so that we define "Standard" before we start talking about
+it and cleaned out a bunch of redundant rules (in particular 4.2/4 was redone to
+eliminate any talk about what the default pool is; that's defined formally in
+6-6.3/4 and it had gotten very complex). Note that the rearrangement changes the
+paragraph numbers in some cases (can't be helped, since we can't insert between
+inserted paragraphs).
+
+And (horrors!) the existing wording for paragraph 5/3 has a "must" in it --
+changed to "shall".
+
+(The paragraphs marked /4 are changed by this AI or by previously approved
+AI12-0136-1. All paragraphs marked /3 are unchanged.)
+
+Comments welcome (but only until Monday). The introductory sentence in
+particular could use some improvement. We'll letter ballot the resulting AI,
+since I changed it so heavily.
+
+                Randy.
+
+================
+
+13.11.3 Default Storage Pools
+
+
+1/4
+Redundant[Pragma and aspect Default_Storage_Pool specify the pool that will be
+used in the absence of an explicit specification for an access type.]
+
+Syntax
+2/3 The form of a pragma Default_Storage_Pool is as follows:
+
+   pragma Default_Storage_Pool (storage_pool_indicator);
+
+3.1/3
+   storage_pool_indicator ::= storage_pool_name | null | Standard
+
+3.2/3
+A pragma Default_Storage_Pool is allowed immediately within the visible part of
+a package_specification, immediately within a declarative_part, or as a
+configuration pragma.
+
+Name Resolution Rules
+3.3/3
+The storage_pool_name is expected to be of type Root_Storage_Pool'Class.
+
+Legality Rules
+4/3
+The storage_pool_name shall denote a variable.
+
+4.1/4
+The Standard storage_pool_indicator is an identifier specific to a pragma (see
+2.8) and does not denote any declaration. If the storage_pool_indicator is
+Standard, then there shall not be a declaration with defining identifier
+Standard that is immediately visible at the point of the pragma, other than
+package Standard itself.
+
+4.2/4 -- number changed
+If the pragma is used as a configuration pragma, the storage_pool_indicator
+shall be either null or Standard, and it defines the default pool as that
+storage_pool_indicator within all applicable compilation units (see 10.1.5),
+except within the immediate scope of another pragma Default_Storage_Pool.
+Otherwise, Redundant[the pragma occurs immediately within a sequence of
+declarations, and] it defines the default pool as that storage_pool_indicator
+within the immediate scope of the pragma, except within the immediate scope of a
+later pragma Default_Storage_Pool. Redundant[Thus, an inner pragma overrides an
+outer one.]
+
+4.3/4 -- only number changed
+A pragma Default_Storage_Pool shall not be used as a configuration pragma that
+applies to a compilation unit that is within the immediate scope of another
+pragma Default_Storage_Pool.
+
+Static Semantics
+5/4
+The language-defined aspect Default_Storage_Pool may be specified for a generic
+instance; it defines the default pool for access types within an instance. The
+Default_Storage_Pool aspect may be specified as Standard, which is an identifier
+specific to an aspect (see 13.1.1) and defines the default pool to be Standard.
+When the Default_Storage_Pool aspect is specified as Standard, then there shall
+not be a declaration with defining identifier Standard that is immediately
+visible at the point of the aspect, other than package Standard itself.
+
+5.1/4
+Otherwise, the expected type for the Default_Storage_Pool aspect is
+Root_Storage_Pool'Class and the aspect_definition shall be a name that denotes a
+variable. This aspect overrides any Default_Storage_Pool pragma that might apply
+to the generic unit; if the aspect is not specified, the default pool of the
+instance is that defined for the generic unit.
+
+5.2/4
+The effect of specifying the aspect Default_Storage_Pool on an instance of a
+language-defined generic unit is implementation-defined.
+
+6/3
+For nonderived access types declared in places where the default pool is defined
+by the pragma or aspect, their Storage_Pool or Storage_Size attribute is
+determined as follows, unless Storage_Pool or Storage_Size is specified for the
+type:
+
+6.1/3
+If the default pool is null, the Storage_Size attribute is defined by the
+language to be zero. [Therefore, an allocator for such a type is illegal.]
+
+6.2/4
+If the default pool is neither null nor Standard, the Storage_Pool attribute is
+that pool.
+
+6.3/4
+Otherwise {(including when the default pool is specified as Standard)}, the
+standard storage pool is used for the type as described in 13.11.
+
+[There is no paragraph 7]
+
+Implementation Permissions
+
+8/3
+An object created by an allocator that is passed as the actual parameter to an
+access parameter may be allocated on the stack, and automatically reclaimed,
+regardless of the default pool.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent