CVS difference for ai05s/ai05-0183-1.txt
--- ai05s/ai05-0183-1.txt 2010/10/26 05:39:47 1.12
+++ ai05s/ai05-0183-1.txt 2010/11/18 07:07:35 1.13
@@ -1825,3 +1825,1106 @@
"warning: since type& is frozen here"
****************************************************************
+
+From: Brad Moore
+Sent: Friday, November 12, 2010 8:24 AM
+
+> Well, I did say I only had brief glimpses but it did seem that there was the
+> risk of confusion with multiple use of with.
+
+I'm wondering if it's a bit messy that the aspect syntax for a package
+declaration ends up being quite different than the aspect syntax for a package
+instance declaration. In the first case, the aspects come immediately before the
+"is", and in the second case they comes a long ways after the "is". This is the
+reason my previous example had the incorrect syntax. I had mistakenly assumed
+that aspects for all package declarations came before the "is". I wonder how
+many others will make that same mistake.
+
+Instead of writing;
+
+package P1 with Pure is
+end P1;
+
+package P2 is new P3 with Pure;
+
+Would it be better to write?
+
+package P1 with Pure is
+end P1;
+
+package P2 with Pure is new P3;
+
+In the case of the instantiation, it seems clearer to me that the Pure attribute
+is now being associated with the new package, rather than somehow being
+associated with the original package.
+
+If package declarations are a special case for aspect syntax, maybe package
+instance declarations should be lumped into that special case as well.
+
+I suppose one might argue that its better to limit the special case as much as
+possible, rather than have it creep into other syntax forms.
+
+On the other hand, maybe all aspect clauses should come before the "is", This
+would eliminate the special case, and might make things more consistent.
+
+Some examples ...
+
+full_type_declaration example-------------------------
+
+type T1 (Length : Integer) with pack is
+ record
+ S : String (1 .. Length);
+ end record;
+
+instead of
+
+type T1 (Length : Integer) is
+ record
+ S : String (1 .. Length);
+ end record with pack;
+
+task type declaration aspects already come before the is -----------
+
+protected type declaration aspects already come before the is ---------
+
+private type declaration example ---------------------
+
+type T1 (Length : Integer) with pack is limited private;
+instead of
+type T1 (Length : Integer) is limited private with pack;
+
+private extension declaration example -------------------
+
+type T1 (Length : Integer) with pack is new limited T2 with private;
+instead of
+type T1 (Length : Integer) is new limited T2 with private with pack;
+
+(I find these last two examples particularly compelling. The fact that this is
+an incomplete declaration can get lost in the declaration. I think private
+should be the last word)
+
+object declarations don't have an is ---------------------
+
+function and procedure specifications don't have an is -------------
+
+This is not an exhaustive list of examples, but I don't see any others offhand
+that would be problematic. In many cases I find the declarations read better
+having the aspect come before the is.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, November 12, 2010 8:32 AM
+
+> I'm wondering if it's a bit messy that the aspect syntax for a package
+> declaration ends up being quite different than the aspect syntax for a
+> package instance declaration. In the first case, the aspects come
+> immediately before the "is", and in the second case they comes a long
+> ways after the "is". This is the reason my previous example had the
+> incorrect syntax. I had mistakenly assumed that aspects for all
+> package declarations came before the "is". I wonder how many others
+> will make that same mistake.
+
+Actually GNAT has this wrong, and it is a huge pain, because it means you have
+to get all the way through the aspects then start looking at what is after IS,
+to know that the aspects you have parsed do not belong there. This is really
+messy.
+
+I agree with Brad, this is confusing, I would always put the aspects before IS
+for all the program unit type syntax.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, November 12, 2010 8:52 AM
+
+I agree that the placement of the aspect specification is a bit tricky. I
+actually found the placement before the "is new" quite jarring. But it is
+annoying that the placement jumps around depending on the construct. The one
+that seems hardest for me to remember is the one for a record type.
+
+The general rule is that it comes just before the ";" except for a non-instance
+package specification, task declaration, or protected declaration, where it
+comes just before the "is".
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, November 12, 2010 9:07 AM
+
+> In many cases I find the declarations read better having the aspect
+> come before the is.
+
+Hmm. I think I agree.
+
+The "with private with Pack" syntax seems particularly odd.
+
+****************************************************************
+
+From: Stephen Michell
+Sent: Friday, November 12, 2010 11:07 AM
+
+Good catch Brad. I think that you explained that well.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, November 12, 2010 11:26 AM
+
+What about "type T is new Integer;"?
+Or "procedure Foo(X: Integer) is null;".
+And what about "renames"? Is "renames" like "is"?
+
+Not an easy choice...
+On the other hand, once we make it, the compiler will help us all learn what is
+the right way to do it. ;-)
+
+I think I still somewhat prefer seeing aspect specifications at the end unless
+that is ridiculously far away as in a non-instance package spec. This is
+especially true if they start getting complex, as in:
+
+ with Dynamic_Predicate =>
+ Sorted_Arr_Type(Arr_Type'First) <= Sorted_Arr_Type(Arr_Type'Last)
+
+This seems like something that doesn't want to be interspersed in the middle of
+an array type definition.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, November 12, 2010 4:30 PM
+
+> What about "type T is new Integer;"?
+> Or "procedure Foo(X: Integer) is null;".
+> And what about "renames"? Is "renames" like "is"?
+
+The last isn't possible: we don't allow aspects on renames. (Aspects are the
+same as those from the renamed object, since they're not view-specific.)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, November 13, 2010 5:26 AM
+
+> What about "type T is new Integer;"?
+
+No one is suggesting the change here, don't use it as a strawman.
+
+> Or "procedure Foo(X: Integer) is null;".
+
+No one is suggesting the change here, don't use it as a strawman.
+
+> And what about "renames"? Is "renames" like "is"?
+
+No, it isn't, no one has suggested that either.
+
+The suggestion is simply to treat the unit cases differently and uniformly.
+
+> I think I still somewhat prefer seeing aspect specifications at the
+> end unless that is ridiculously far away as in a non-instance package
+> spec.
+> This is especially true if they start getting complex, as in:
+>
+> with Dynamic_Predicate =>
+> Sorted_Arr_Type(Arr_Type'First)<= Sorted_Arr_Type(Arr_Type'Last)
+>
+> This seems like something that doesn't want to be interspersed in the
+> middle of an array type definition.
+
+No one is suggesting interspersing this, don't use it as a strawman :-)
+
+The suggesting is that we should have uniform treatment for
+
+ package pack is bla;
+
+regardless of what bla is, and I think that's a real improvement over what you
+propose. To me it is just weird (to the parser and to a human reader to have)
+
+ package pack with
+ lots of aspects
+ is
+
+and still not know if the aspects belonged there. It's not hard to implement
+in the parser of course, but it's a real oddity to treat these cases
+differently, and will surely cause confusion.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, November 13, 2010 5:27 AM
+
+>> What about "type T is new Integer;"?
+>> Or "procedure Foo(X: Integer) is null;".
+>> And what about "renames"? Is "renames" like "is"?
+>
+> The last isn't possible: we don't allow aspects on renames. (Aspects
+> are the same as those from the renamed object, since they're not
+> view-specific.)
+
+Personally I would prefer the rule to be that we allow aspects, but none of the
+language ones can be used for renamings, since that allows useful use of the
+notation for implementation defined aspects, but it's not a big deal, and if we
+have an arbitrary limitation that prevents this, we can live with it.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, November 13, 2010 7:50 AM
+
+> Personally I would prefer the rule to be that we allow aspects, but
+> none of the language ones can be used for renamings, since that allows
+> useful use of the notation for implementation defined aspects, ...
+
+I agree.
+
+>...but it's not a
+> big deal, and if we have an arbitrary limitation that prevents this,
+>we can live with it.
+
+That, too.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, November 13, 2010 7:44 AM
+
+> > What about "type T is new Integer;"?
+>
+> No one is suggesting the change here, don't use it as a strawman.
+...
+> The suggestion is simply to treat the unit cases differently and
+> uniformly.
+
+Brad's suggestion goes further than that, so I don't see any "straw men" from
+Tucker.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Saturday, November 13, 2010 10:42 AM
+
+> The general rule is that it comes just before the ";" except for a
+> non-instance package specification, task declaration, or protected
+> declaration, where it comes just before the "is".
+
+There is something to be said though, for simpler rules being easier to
+memorize.
+
+E.g. It always comes before "is", otherwise comes before ";"
+
+> What about "type T is new Integer;"?
+
+I find this to be a similar case to the package instantiation declaration.
+If the aspects are at the end, it might be confusing for a novice because one
+might think the aspects are somehow defining requirements on the base type. If
+they come after the type name it is clearer that they apply to the new type.
+
+eg.
+
+type T is new Foo with Atomic;
+
+vs
+
+type T with Atomic is new Foo;
+
+
+> Or "procedure Foo(X: Integer) is null;".
+
+I find this case to be similar to the private type and private extension case.
+
+The important part of the declaration is that it is a null procedure.
+If the aspects at the end, the "is null" might get lost in the text.
+
+eg.
+
+ procedure Foo (C : Class; X : in out Integer)
+ is null
+ with Pre'Class => X = 0, Post'Class => X > 0; vs
+ procedure Foo (C : Class; X : in out Integer)
+ with Pre'Class => X = 0, Post'Class => X > 0
+ is null;
+
+> And what about "renames"? Is "renames" like "is"?
+
+According to the latest version of AI 183, aspects are not permitted on renaming
+declarations. Is that still correct?
+
+> I think I still somewhat prefer seeing aspect specifications at the
+> end unless that is ridiculously far away as in a non-instance package
+> spec.
+> This is especially true if they start getting complex, as in:
+>
+> with Dynamic_Predicate =>
+> Sorted_Arr_Type(Arr_Type'First) <= Sorted_Arr_Type(Arr_Type'Last)
+>
+> This seems like something that doesn't want to be interspersed in the
+> middle of an array type definition.
+
+I share your concern. It might end up looking weird if it appears that a bunch
+of code occurs in the middle of a declaration.
+
+type Sorted_Arr_Type is array (Integer range <>) of Foo
+ with Dynamic_Predicate =>
+ Sorted_Arr_Type(Arr_Type'First) <= Sorted_Arr_Type(Arr_Type'Last) ;
+
+vs
+
+type Sorted_Arr_Type
+ with Dynamic_Predicate =>
+ Sorted_Arr_Type(Arr_Type'First) <= Sorted_Arr_Type(Arr_Type'Last)
+ is array (Integer range <>) of Foo;
+
+The first version is more pleasing to my eye, though the second isn't horrible.
+I think I like the first better in this case, because it fits better on
+3 lines.
+The second one "looks" bigger.
+
+With shorter aspects, I find my preference goes the other way.
+
+eg
+
+I like
+type Sorted_Arr_Type with Atomic_Components is array (Integer range <>) of Foo;
+
+better than
+
+type Sorted_Arr_Type is array (Integer range <>) of Foo with Atomic_Components;
+
+Probably to convince ourselves one way or the other, we need to look at a more
+complete set of examples.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, November 13, 2010 10:44 AM
+
+>>> What about "type T is new Integer;"?
+>>
+>> No one is suggesting the change here, don't use it as a strawman.
+> ...
+>> The suggestion is simply to treat the unit cases differently and
+>> uniformly.
+>
+> Brad's suggestion goes further than that, so I don't see any "straw
+> men" from Tucker.
+
+Correct. I was reacting to Brad's suggestion that we move *all*
+aspect_specifications before the "is", including on "normal" type definitions.
+I understand Brad's motivation, but I was illustrating why I think it would be
+unwise.
+
+As far as package instantiations, I can see accept it either way, though I did
+react somewhat negatively when I first saw it before the "is new".
+
+I presume we are not allowing aspect specifications on bodies. If we were, then
+I would wonder where the aspect_specification should go on:
+
+ procedure Blubber(...) is null/abstract;
+
+Before the "is" or before the ";".
+Ditto for a subprogram instantiation.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Saturday, November 13, 2010 10:55 AM
+
+> I find this to be a similar case to the package instantiation declaration.
+> If the aspects are at the end, it might be confusing for a novice
+> because one might think the aspects are somehow defining requirements
+> on the base type. If they come after the type name it is clearer that
+> they apply to the new type.
+>
+> eg.
+>
+> type T is new Foo with Atomic;
+>
+> vs
+>
+> type T with Atomic is new Foo;
+
+I prefer the first one, because I read it as "type T is a foo, with an extra
+property: it is atomic".
+
+[...]
+> Probably to convince ourselves one way or the other, we need to look
+> at a more complete set of examples.
+
+I fully agree with that statement!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, November 13, 2010 8:23 PM
+
+> Brad's suggestion goes further than that, so I don't see any "straw
+> men" from Tucker.
+
+I had not realized that Brad was suggesting
+
+ type x is array with size => 64 of ...
+
+I find that suggestion ludicrous, are you really sure Brad was suggesting this?
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, November 13, 2010 8:28 PM
+
+> type T is new Foo with Atomic;
+>
+> vs
+>
+> type T with Atomic is new Foo;
+
+So Brad really *was* suggesting this. Apologies for the straw man comment to
+Tuck.
+
+Well I think it is simply horrible to read, and do not support this change at
+all.
+
+> eg.
+>
+> procedure Foo (C : Class; X : in out Integer)
+> is null
+> with Pre'Class => X = 0, Post'Class => X> 0; vs
+> procedure Foo (C : Class; X : in out Integer)
+> with Pre'Class => X = 0, Post'Class => X> 0
+> is null;
+
+Again, IMO horrible! I really dislike putting aspects before the IS in these
+cases.
+
+> Probably to convince ourselves one way or the other, we need to look
+> at a more complete set of examples.
+
+Except for the package case which we are still discussing, I think we have a
+fine set of rules now, and I see no significant argument for changing them.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, November 13, 2010 8:29 PM
+
+> Correct. I was reacting to Brad's suggestion that we move *all*
+> aspect_specifications before the "is", including on "normal" type
+> definitions. I understand Brad's motivation, but I was illustrating
+> why I think it would be unwise.
+
+I 100% agree with you Tuck on this!
+
+****************************************************************
+
+From: Brad Moore
+Sent: Saturday, November 13, 2010 10:03 PM
+
+>> type T is new Foo with Atomic;
+>>
+>> vs
+>>
+>> type T with Atomic is new Foo;
+>
+> So Brad really *was* suggesting this. Apologies for the straw man
+> comment to Tuck.
+
+Well, I actually had two independent suggestions.
+
+One was just do deal with the package instantiation case, and the other was a
+more general suggestion as an attempt to bring a more consistent approach with
+regard to aspect placement when "is" is present.
+
+For the package instantiation case, you convinced me a while back that the
+aspect on a package declaration has to come before the "is". That suggests to me
+that to do anything about the package instantiation case, the aspect would
+likely also have to come before the "is", unless someone comes up with a better
+idea.
+
+
+Just curious though,
+
+Do you also prefer
+
+type T is new Foo with private with pack;
+
+over
+
+type T with pack is new Foo with private;
+
+Having two with's connected together with very different meaning seems like it
+could be a source of confusion, and I imagine might be awkward to explain to a
+class of Ada 101 students.
+
+Maybe it would be nice if we could combine the two with's into one, and treat
+private as a sort of pseudo-aspect for private types and private extensions.
+
+eg.
+
+type T is new Foo with private, pack;
+
+I suspect that I've already stirred up enough with my previous suggestions.
+I think I better put on my asbestos suit and crash helmet.... :-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, November 14, 2010 9:58 AM
+
+(grab flame thrower!)
+
+> For the package instantiation case, you convinced me a while back that
+> the aspect on a package declaration has to come before the "is". That
+> suggests to me that to do anything about the package instantiation
+> case, the aspect would likely also have to come before the "is",
+> unless someone comes up with a better idea.
+
+It doesn't *have* to come before the IS, I slightly prefer that it does, but can
+live with Tuck's viewpoint, and the latter has the advantage of being the status
+quo!
+
+> Just curious though,
+>
+> Do you also prefer
+>
+> type T is new Foo with private with pack;
+
+Yes, I prefer this consistent form, even though depending how you write it, it
+could be confusing, for me, the format would always be
+
+ type T is new Foo with private with
+ Pack => True;
+
+BTW I think I *do* prefer to keep the => True possibility (again has the
+advantage of being the status quo), precisely because it makes it very clear
+that you are talking about the aspect case syntactically. I would not insist on
+it, but I would usually use it I think in a case like this.
+
+> over
+>
+> type T with pack is new Foo with private;
+>
+> Having two with's connected together with very different meaning seems
+> like it could be a source of confusion, and I imagine might be awkward
+> to explain to a class of Ada 101 students.
+
+I doubt this (illegal) form would be a likely discussing item in Ada 101, and I
+really don't think it's such a problem anyway.
+
+> Maybe it would be nice if we could combine the two with's into one,
+> and treat private as a sort of pseudo-aspect for private types and
+> private extensions.
+>
+> eg.
+>
+> type T is new Foo with private, pack;
+
+Absolutely not, this is a gratitous and troublesome change in existing syntax.
+
+> I suspect that I've already stirred up enough with my previous suggestions.
+> I think I better put on my asbestos suit and crash helmet.... :-)
+
+suit up!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 15, 2010 4:15 PM
+
+...
+> Well, I actually had two independent suggestions.
+>
+> One was just do deal with the package instantiation case, and the
+> other was a more general suggestion as an attempt to bring a more
+> consistent approach with regard to aspect placement when "is" is
+> present.
+>
+> For the package instantiation case, you convinced me a while back that
+> the aspect on a package declaration has to come before the "is". That
+> suggests to me that to do anything about the package instantiation
+> case, the aspect would likely also have to come before the "is",
+> unless someone comes up with a better idea.
+
+I sympathize with this position.
+
+But keep in mind that presuming that we leave aspect clause placement for
+subprograms as it is, we have a nasty problem with instances, in that they are
+used both for subprograms and packages. (And I'm presuming that subprograms are
+left as is since the current syntax reads the best for Pre and Post.)
+
+Given that subprograms are written thus:
+
+ procedure Pro (A, B : in Integer) with Pre => A > B;
+
+and packages are written thus:
+
+ package Pack with Pure => True is
+ ...
+
+we have three choices for instantiations:
+
+(1) Always at the end (like subprograms); the existing proposal:
+
+ procedure Pro is new Gen_Pro with Inline => True;
+
+ package Pack is new Gen_Pack with Pure => True;
+
+(2) Always before the is (like packages); the new proposal (I think):
+
+ procedure Pro with Inline => True is new Gen_Pro;
+
+ package Pack with Pure => True is new Gen_Pack;
+
+(3) Always the same as the associated non-generic entity:
+
+ procedure Pro is new Gen_Pro with Inline => True;
+
+ package Pack with Pure => True is new Gen_Pack;
+
+
+(1) is inconsistent with packages; (2) is inconsistent with subprograms; and
+(3) is inconsistent between types of instantations. This doesn't seem
+particularly good no matter what we choose.
+
+I do think package instantiations are more common than subprogram instantations,
+so that argues for using (2) or (3). I think I slightly lean toward (3), but
+none of them is clearly better than the others.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, November 15, 2010 4:46 PM
+
+I think I still prefer choice (1), that is, the current AI wording. Putting
+more stuff into the middle of an instantiation seems unwieldy.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, November 15, 2010 5:28 PM
+
+I agree with this, and plan to change the GNAT implementation to conform with
+this thinking.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Monday, November 15, 2010 7:27 PM
+
+> (1) is inconsistent with packages; (2) is inconsistent with
+> subprograms; and
+> (3) is inconsistent between types of instantations. This doesn't seem
+> particularly good no matter what we choose.
+>
+> I do think package instantiations are more common than subprogram
+> instantations, so that argues for using (2) or (3). I think I slightly
+> lean toward (3), but none of them is clearly better than the others.
+
+Actually, there is one other set of possibilities which so far has not been
+discussed, (to the best of my knowledge).
+
+This again comes as two separate somewhat independent suggestions.
+
+1) To just fix the package declaration case, move the aspect to immediately
+before the semi-colon.
+
+eg.
+ package Ada is
+ end Ada with Pure;
+
+For a larger package declaration the aspect comes long after where the pragma
+would typically appear. However, this might be something we get used to, perhaps
+a small price to pay for having a more consistent syntax.
+
+I suspect for smaller, simpler package specs, this form would generally be
+preferable to using pragmas. For larger packages, it may be a style preference,
+but there's nothing saying you can't still use pragmas, if you think that makes
+better sense.
+
+Since I had my eyebrows singed from yesterdays email :-) , I might as well
+continue with my other suggestion, which you can probably already guess.
+
+2) That is, we could say that *all* aspect syntax always comes immediately
+before the semi-colon.
+
+This would make for a very simple rule for people to remember.
+
+It only impacts task type and protected type declarations (and package
+declarations), as those are the only syntax forms where aspect clauses come
+before the "is".
+
+Again, it might take a bit of getting used to, but might be worthwhile if the
+benefits outweigh the costs.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, November 15, 2010 7:57 PM
+
+> eg.
+> package Ada is
+> end Ada with Pure;
+
+I *very* strongly dislike this, you really want to see the Pure or Preelaborate
+at the start of the package and not at the end of the private part. This is why
+we require the pragmas to be at the start after all.
+
+> I suspect for smaller, simpler package specs, this form would
+> generally be preferable to using pragmas. For larger packages, it may
+> be a style preference, but there's nothing saying you can't still use
+> pragmas, if you think that makes better sense.
+
+You are saying "we did a bad job of designing placement of attributes so in a
+large package [almost any package is large enough as far as I am concerned] you
+won't be happy using the lousily designed aspect syntax. Never mind, we were
+forced to keep the pragmas for compatibility reasons, so you can still use
+those.
+
+> Since I had my eyebrows singed from yesterdays email :-) , I might as
+> well continue with my other suggestion, which you can probably already
+> guess.
+>
+> 2) That is, we could say that *all* aspect syntax always comes
+> immediately before the semi-colon.
+>
+> This would make for a very simple rule for people to remember.
+>
+> It only impacts task type and protected type declarations (and package
+> declarations), as those are the only syntax forms where aspect clauses
+> come before the "is".
+>
+> Again, it might take a bit of getting used to, but might be worthwhile
+> if the benefits outweigh the costs.
+
+Again, simply horrible, this is consistency gone mad!
+
+At this stage, I am strongly in favor of maintaining the status quo as written
+up. The suggestions for changing it seem to be opening up a can of worms (aka
+horrible suggestions for changing things).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 15, 2010 8:05 PM
+
+...
+> This again comes as two separate somewhat independent suggestions.
+>
+> 1) To just fix the package declaration case, move the aspect to
+> immediately before the semi-colon.
+>
+> eg.
+> package Ada is
+> end Ada with Pure;
+>
+> For a larger package declaration the aspect comes long after where the
+> pragma would typically appear.
+> However, this might be something we get used to, perhaps a small price
+> to pay for having a more consistent syntax.
+
+It's not about "getting used to it". It's about adding a whole lot of
+implementation difficulty. "Pragma Pure" is implemented by setting a compiler
+flag or state, and then checking each declaration as it appears whether it meets
+the requirements of that flag/state. That cannot be done if the aspect is at the
+end.
+
+The same holds anytime the aspect can affect the legality of the contents; that
+is, anytime there are significant independent declarations inside of the entity.
+Which is the program unit cases that you don't like.
+
+If we were to move the aspects to the end, then we'd have to drop the idea of
+converting program-unit pragmas into aspects, and quite possibly also have to
+drop and heavily modify various other aspects. (Effectively, we couldn't require
+any program unit aspects other than executable ones, because they wouldn't be
+implementable.)
+
+Honestly, you had a better argument when you suggested moving everything in
+front of the "is". That's only really ugly for types (subprograms usually don't
+have an "is" when they'd also have aspects). But since types are likely to be
+common
+
+I think readability and implementability trumps consistency here. The only sane
+alternative would be to drop the aspect syntax altogether from units, which
+*still* would be inconsistent, and we'd be losing a number of capabilities (most
+of the ones I care about, apart from the contracts stuff).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 15, 2010 8:07 PM
+
+...
+> At this stage, I am strongly in favor of maintaining the status quo as
+> written up. The suggestions for changing it seem to be opening up a
+> can of worms (aka horrible suggestions for changing things).
+
+Yup. The more we look at alternatives, the more it looks like we got it right
+the second time (the first time it was more like Brad's suggestion(s), which
+doesn't work very well.)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, November 15, 2010 8:13 PM
+
+> It's not about "getting used to it". It's about adding a whole lot of
+> implementation difficulty. "Pragma Pure" is implemented by setting a
+> compiler flag or state, and then checking each declaration as it
+> appears whether it meets the requirements of that flag/state. That
+> cannot be done if the aspect is at the end.
+
+And even if we fiddle in the compiler (e.g. by looking ahead and parsing the
+aspects first, which is actually likely to be pretty trivial in most compilers,
+probably Randy's compiler is an exception), the point is that the same thing
+that makes this awkward for the compiler makes things awkward for a reader.
+
+Basically a reader (or a one pass compiler) wants to know things at the
+appropriate point, and you definitely want to know that a package is pure as you
+read it.
+
+> If we were to move the aspects to the end, then we'd have to drop the
+> idea of converting program-unit pragmas into aspects, and quite
+> possibly also have to drop and heavily modify various other aspects.
+> (Effectively, we couldn't require any program unit aspects other than
+> executable ones, because they wouldn't be implementable.)
+
+Saying they are not implementable is much too strong, what Randy means is "I
+would have a hard time implementing them in my compiler", it actually would be
+trivial in GNAT, since as is more typical of Ada compilers, it builds a parse
+tree, then starts the semantic analysis.
+
+To me the stronger argument is difficulty for the reader, and in that sense,
+Randy's one pass compiler is a useful test, if he has trouble, then so will a
+reader of the code!
+
+> Honestly, you had a better argument when you suggested moving
+> everything in front of the "is". That's only really ugly for types
+> (subprograms usually don't have an "is" when they'd also have
+> aspects). But since types are likely to be common
+>
+> I think readability and implementability trumps consistency here. The
+> only sane alternative would be to drop the aspect syntax altogether
+> from units, which *still* would be inconsistent, and we'd be losing a
+> number of capabilities (most of the ones I care about, apart from the
+> contracts stuff).
+
+So Randy, are you comfortable signing up for the status quo? Sounds like it, and
+that's what Tuck prefers. Really I see only Brad at this stage suggesting any
+other action.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Monday, November 15, 2010 10:16 PM
+
+> So Randy, are you comfortable signing up for the status quo? Sounds
+> like it, and that's what Tuck prefers. Really I see only Brad at this
+> stage suggesting any other action.
+
+I see aspect specifications as an important new feature of the language.
+At the end of the day, I'd like to be able to say that we got it right.
+Knowing that we've considered all the possibilities will go a long way towards
+feeling comfortable with whatever decision we make. (Surely we've covered all
+the possibilities ...) It's too bad that there isn't one solution that fits
+perfectly, but I can be happy with the status quo.
+
+Arguing now for the status quo, I would say that if people get mixed up and try
+to put aspects in the wrong place, then I would think it should be easy enough
+for the compiler to give a clear error message hopefully that will tell the
+programmer where the aspect needs to be placed. I think people will quickly get
+the hang of it....
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, November 15, 2010 8:17 PM
+
+> > eg.
+> > package Ada is
+> > end Ada with Pure;
+>
+> I *very* strongly dislike this, you really want to see the Pure or
+> Preelaborate at the start of the package and not at the end of the
+> private part. This is why we require the pragmas to be at the start
+> after all.
+
+Which is why I'm pretty happy with the pragmas. Yeah, I get that this
+new-fangled aspect thing is wonderful, but I'm nervous about how much trouble
+we're willing to go to...
+
+The main advantage of aspect clauses is that you don't have to name the thing.
+Saying "Foo is an inlined function." is fundamentally simpler than "Foo is a
+function. Foo is inlined." because in the latter case, the reader has to match
+up the two occurrences of "Foo". (The former is English for the aspect syntax;
+the latter for pragma syntax.)
+
+But Pure doesn't have that problem -- you can just say "pragma Pure;" and it
+refers to "this package". So I don't see why we want to go to a whole lot of
+trouble to make "Pure" into an aspect.
+
+Especially since I got "volunteered" to write up the wording that causes
+everything under the sun to be an "aspect".
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, November 16, 2010 5:49 AM
+
+> But Pure doesn't have that problem -- you can just say "pragma Pure;"
+> and it refers to "this package".
+> So I don't see why we want to go to a whole lot of trouble to make
+> "Pure" into an aspect.
+
+I like the aspect notation for Pure, and I don't see it as a big deal, Certainly
+the implementation is trivial (and for GNAT, already done), and the description
+is done, so I am not sure what the "whole lot of trouble" you are talking about
+might be.
+
+> Especially since I got "volunteered" to write up the wording that
+> causes everything under the sun to be an "aspect".
+
+But that part of it is done :-)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, November 16, 2010 6:57 AM
+
+It's not done. It's on my to-do list.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, November 16, 2010 7:01 AM
+
+But the syntax is done, right, which is the issue here.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, November 16, 2010 5:51 AM
+
+> Arguing now for the status quo, I would say that if people get mixed
+> up and try to put aspects in the wrong place, then I would think it
+> should be easy enough for the compiler to give a clear error message
+> hopefully that will tell the programmer where the aspect needs to be
+> placed.
+
+Indeed, not hard to do at all.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, November 16, 2010 7:06 AM
+
+Note that it is the syntax that is important to decide on and get into the RM.
+
+To me it doesn't matter so much whether the ARG decides to allow or disallow
+e.g. the Pure aspect, since once the syntax is OK, then implementations can
+implement any aspects they want.
+
+Which is why I would still like to see the *syntax* allow aspects on renamings,
+even if there are no officially allowed aspects.
+
+After all we allow a pragma Inline to apply to a renaming, so it seems quite
+arbitrary to say
+
+pragma Inline can be replaced with an Inline aspect, except for renamings, where
+only the pragma is allowed, and the aspect is illegal.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, November 16, 2010 8:45 AM
+
+> But the syntax is done, right, which is the issue here.
+
+Yes, there is a propoosed syntax, although it's still being discussed. At this
+point, I tend to agree with you and Tucker that the current propoosed syntax is
+the best we're going to get.
+
+Whether or not Pure is an aspect is still open -- no proposal one way or
+'tother. I don't see much point in it, but maybe it's just for uniformity,
+which I can't tell without looking at the whole list of potential aspects.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, November 16, 2010 10:04 AM
+
+>> But the syntax is done, right, which is the issue here.
+>
+> Yes, there is a propoosed syntax, although it's still being discussed.
+> At this point, I tend to agree with you and Tucker that the current
+> propoosed syntax is the best we're going to get.
+
+And Brad seems to agree too :-) So let's just decide to stick with this syntax.
+
+> Whether or not Pure is an aspect is still open -- no proposal one way
+> or 'tother. I don't see much point in it, but maybe it's just for
+> uniformity, which I can't tell without looking at the whole list of
+> potential aspects.
+
+Well as I say, it's not critical what the resolution is.
+I am in favor of including this aspect, since I like the idea of not relying on
+pragmas for this kind of important semantic stuff.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, November 16, 2010 10:06 AM
+
+> Arguing now for the status quo, I would say that if people get mixed
+> up and try to put aspects in the wrong place, then I would think it
+> should be easy enough for the compiler to give a clear error message
+> hopefully that will tell the programmer where the aspect needs to be
+> placed
+
+How about
+
+> 1. pragma Ada_2012;
+> 2. package AspectInst is
+> 3. generic package P with -- OK
+> 4. Pure
+> 5. is
+> 6. end;
+> 7.
+> 8. generic package P2 is -- ERROR
+> |
+> >>> info: aspect specifications belong here
+>
+> 9. end with
+> |
+> >>> misplaced aspects for package declaration
+>
+> 10. Pure;
+> 11.
+> 12. package PP is new P with -- OK
+> 13. Pure;
+> 14.
+> 15. package PQ with -- ERROR
+> |
+> >>> misplaced aspects for package instantiation
+>
+> 16. Pure
+> 17. is new P;
+> |
+> >>> info: aspect specifications belong here
+>
+> 18. end;
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, November 18, 2010 12:40 AM
+
+...
+> Note that it is the syntax that is important to decide on and get into
+> the RM.
+
+The syntax *is* in the RM already, just look at draft 10 or later. :-)
+
+http://www.ada-auth.org/standards/ada12.html
+
+Of course, everything in the draft RM is subject to change. But I've only put
+things into it that I think are pretty stable (don't want to redo work).
+
+****************************************************************
Questions? Ask the ACAA Technical Agent