CVS difference for ai05s/ai05-0183-1.txt
--- ai05s/ai05-0183-1.txt 2011/02/15 04:43:41 1.18
+++ ai05s/ai05-0183-1.txt 2011/02/16 06:15:23 1.19
@@ -2990,6 +2990,523 @@
****************************************************************
+From: Randy Brukardt
+Sent: Wednesday, September 1, 2010 10:54 PM
+
+I'm putting the wording of this AI into the standard, and got mildly confused
+over the meaning of "names" in wording like:
+
+The names in an @fa<aspect_definition> are not resolved at the point of the
+associated declaration, but rather are resolved at the end of the immediately
+enclosing declaration list, or at the first freezing point of the associated
+entity, whichever comes first.
+
+I was wondering if this meant "name"s as in the syntax of 4.1, or really meant
+identifiers and the like. Looking in 8.6, it uses "usage names" for the latter
+(and this term is defined in 3.1(10) for this use). I suspect that this text in
+AI05-0183-1 ought to be using "usage names" here and in similar paragraphs.
+
+P.S. Note that this AI is still open and assigned to Tucker; I'm making some
+rough fixes before putting part of it into the Standard (it has to be there so
+that syntax references from other, approved AIs work).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, September 2, 2010 2:14 AM
+
+What I have implemented for this in GNAT is that for aspects
+precondition/postcondition, the resolution is delayed as described above.
+
+For other aspects, such as size, the expression is treated like a default
+initial expression, the names are resolved at the point of appearence, but
+evaluation of the expression and associated freeing is delayed to the freeze
+point.
+
+I don't think there is any necessity for the kind of special checking that Randy
+suggested that visibililty has not changed by the freeze point, at least for the
+cases other than pre/postconditions, since the situation is no different from
+default initial expressions, and visibility is at the point of occurrence.
+
+For pre/postconditions, the situation that Randy is worrying about is something
+like
+
+ function Complete (A : Integer) is visible at this point
+
+ declare
+ procedure X (A : Integer) with
+ Pre => Complete (A);
+
+ function Complete (A : Integer);
+
+ ....
+
+
+Now in this situation, the Pre gets the inner Complete, not the outer Complete.
+In general you definitely want this possibility of forward referencing for Pre
+and Post since you want to be able to add pre/post conditions without having to
+reorder subprogram declarations. We have implemented this for some time now in
+GNAT with the precondition/postcondition pragmas, and I definitely think that's
+highly useful, even though it is a bit unusual in terms of semantics of
+visibility elsewhere in the language.
+
+The question is, in the unusual situation (never seen it happen in practice) in
+the example above, is the confusion of getting the inner Complete instead of the
+outer Complete worth worrying about.
+
+Three possible answers
+
+a) don't worry about it, that's what we have done in GNAT, and so far, noone has
+ been confused or bothered by such a case.
+
+b) generate a warning, might be nice, not clear it is worth the effort, but in
+ any case, not the job of the standard. I actually think that a warning is
+ worth it in the inverse case:
+
+ function Decorate (A : Integer) return Integer
+ -- visible out here
+
+ declare
+ X : Integer := Decorate (12);
+
+ function Decorate (A : Integer) return Integer;
+
+ ...
+
+
+where we get the outer Decorate instead of the inner one. But this warning would
+be hard work and we have never considered it in GNAT.
+
+c) Make this situation illegal and require a check. I don't like this for two
+ reasons:
+
+ -- It's hard to implement, requiring tinkering in a very
+ delicate area of the compiler
+
+ -- In practice I think there may be cases where you know
+ what you want in the inner region, and it is annoying
+ to have to modify names because of some function in the
+ global environment that you don't know about and don't
+ care about.
+
+BTW, final list of aspects implemented in GNAT is:
+
+> Aspect_Ada_2005, -- GNAT
+> Aspect_Ada_2012, -- GNAT
+> Aspect_Address,
+> Aspect_Alignment,
+> Aspect_Atomic,
+> Aspect_Atomic_Components,
+> Aspect_Bit_Order,
+> Aspect_Component_Size,
+> Aspect_Discard_Names,
+> Aspect_External_Tag,
+> Aspect_Favor_Top_Level, -- GNAT
+> Aspect_Inline,
+> Aspect_Inline_Always, -- GNAT
+> Aspect_Invariant,
+> Aspect_Machine_Radix,
+> Aspect_No_Return,
+> Aspect_Object_Size, -- GNAT
+> Aspect_Pack,
+> Aspect_Persistent_BSS, -- GNAT
+> Aspect_Post,
+> Aspect_Pre,
+> Aspect_Predicate, -- GNAT???
+> Aspect_Preelaborable_Initialization,
+> Aspect_Pure_Function, -- GNAT
+> Aspect_Shared, -- GNAT (equivalent to Atomic)
+> Aspect_Size,
+> Aspect_Storage_Pool,
+> Aspect_Storage_Size,
+> Aspect_Stream_Size,
+> Aspect_Suppress,
+> Aspect_Suppress_Debug_Info, -- GNAT
+> Aspect_Unchecked_Union,
+> Aspect_Universal_Aliasing, -- GNAT
+> Aspect_Unmodified, -- GNAT
+> Aspect_Unreferenced, -- GNAT
+> Aspect_Unreferenced_Objects, -- GNAT
+> Aspect_Unsuppress,
+> Aspect_Value_Size, -- GNAT
+> Aspect_Volatile,
+> Aspect_Volatile_Components,
+> Aspect_Warnings); -- GNAT
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, September 2, 2010 7:41 AM
+
+> Three possible answers
+>
+> a) don't worry about it, that's what we have done in GNAT, and so far,
+> noone has been confused or bothered by such a case.
+
+This is my choice, although I don't think we have evidence that "noone has been confused" -- I'd say, "we don't know of anyone who has been confused or bothered, and it doesn't seem all that likely".
+
+Two reasons:
+
+1. As illustrated by (b) below, this sort of thing already occurs. That's a
+ language design flaw, but we're not going to fix it. The case of (b) is
+ rare, but the case we're talking about here is far more rare, hence silly to
+ worry about.
+
+2. If you didn't design your overload resolution with this in mind, then running
+ overload resolution twice is a huge complication. I would require this in a
+ from-scratch language design, but now it just not worth it.
+
+> b) generate a warning, might be nice, not clear it is worth the
+> effort, but in any case, not the job of the standard. I actually think
+> that a warning is worth it in the inverse case:
+>
+> function Decorate (A : Integer) return Integer
+> -- visible out here
+>
+> declare
+> X : Integer := Decorate (12);
+>
+> function Decorate (A : Integer) return Integer;
+>
+> ...
+>
+>
+> where we get the outer Decorate instead of the inner one. But this
+> warning would be hard work and we have never considered it in GNAT.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, September 2, 2010 7:45 AM
+
+> I was wondering if this meant "name"s as in the syntax of 4.1, or
+> really meant identifiers and the like. Looking in 8.6, it uses "usage
+> names" for the latter (and this term is defined in 3.1(10) for this
+> use). I suspect that this text in AI05-0183-1 ought to be using "usage
+> names" here and in similar paragraphs.
+
+Yes, I think "usage names" would be OK. Or perhaps, "Name Resolution is not
+performed on aspect clauses at the point where they occur, but instead at the
+end...".
+
+The phrase "are not resolved" is pretty informal anyway, so I wouldn't spend too
+much time getting this perfect, so long as we understand what it means.
+
+By the way, in "at the first freezing point of the associated entity", I assume
+the associated entity is the one we're defining an aspect of, not the entity
+denoted by the usage name we're trying to resolve. Right? The latter wouldn't
+make sense.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, September 2, 2010 8:13 AM
+
+Yes, "usage names" is probably more correct.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, September 2, 2010 8:18 AM
+
+> ...
+> By the way, in "at the first freezing point of the associated entity",
+> I assume the associated entity is the one we're defining an aspect of,
+> not the entity denoted by the usage name we're trying to resolve.
+> Right? The latter wouldn't make sense.
+>
+
+The wording includes a definition of the "associated entity"
+I believe, and it is the entity whose aspect is being defined.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, September 2, 2010 3:20 PM
+
+...
+> What I have implemented for this in GNAT is that for aspects
+> precondition/postcondition, the resolution is delayed as described
+> above.
+>
+> For other aspects, such as size, the expression is treated like a
+> default initial expression, the names are resolved at the point of
+> appearence, but evaluation of the expression and associated freeing is
+> delayed to the freeze point.
+
+That doesn't work for subprogram-valued aspects (such as the stream attributes).
+When the type is declared, it's not possible for the stream routines to have
+been declared yet (since they necessarily take the type name). Thus the delay in
+resolution is needed.
+
+[You may have not noticed that as your list of supported aspects seems to be
+missing Read, Write, Input, and Output. :-)]
+
+Given that it is needed in quite a few cases, it seems confusing to have
+different resolution rules for different kinds of aspects. It also makes the
+wording a lot larger, as the resolution rules would have to be described for
+each individual aspect (probably using some simplified description so that the
+entire description wouldn't need to be distributed).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, September 2, 2010 5:45 PM
+
+I still think it would be a big mistake to delay resolution for things like Size
+and Alignment, just plain confusing and unnecessary.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, September 3, 2010 2:02 AM
+
+> That doesn't work for subprogram-valued aspects (such as the stream
+> attributes). When the type is declared, it's not possible for the
+> stream routines to have been declared yet (since they necessarily take
+> the type name). Thus the delay in resolution is needed.
+>
+> [You may have not noticed that as your list of supported aspects seems
+> to be missing Read, Write, Input, and Output. :-)]
+
+I agree these are missing, I was just guessing what should and should not be on
+the list (as you know there is no list in the AI yet :-)
+
+And of course, the delay is required for these.
+
+I do see a somewhat clear distinction between the two classes of attributes, one
+class establishes actions that will be applied when the entity is in use, not
+when it is frozen, and the other supplies simple values that determine the
+representation at freeze time.
+
+> Given that it is needed in quite a few cases, it seems confusing to
+> have different resolution rules for different kinds of aspects. It
+> also makes the wording a lot larger, as the resolution rules would
+> have to be described for each individual aspect (probably using some
+> simplified description so that the entire description wouldn't need to be distributed).
+
+I don't know about a "lot larger", relatively few aspects need this delay, and
+all you need is a central description saying that the evaluation of some aspects
+is delayed bla bla bla, and that these will be identified in separate sections
+on the aspects, and then one sentence in each of the 7 or 8 aspects involved.
+
+I must say that I am not so adamant as I was on avoiding the delay in the other
+(great majority) of cases. It's certainly trivial to do, and in practice it will
+never make a difference.
+
+I would by the way at this stage be VERY opposed to some gizmo that made it an
+error if the delay changes the visibility. This would have the very undesirable
+effect of an outer change making an inner block illegal with no way to defend
+against this in the inner block (that would be something new and undesirable).
+
+I do agree that a warning would be nice
+
+ warning: "ghx" refers to the entity declared on line 27
+ not the entity declared on line 5.
+
+But I looked into it, and generating this warning is definitely not easy. It's
+on the list of enhancements, but I don't know if it will ever get done :-(
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, September 3, 2010 8:24 AM
+
+One distinction we could use is operational aspects vs. representational
+aspects.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, September 2, 2010 2:20 AM
+
+One more point on aspect stuff.
+
+For language defined aspects, we have agreed that aspects can only be specified
+once. Personally I would prefer to allow multiple Pre/Post aspects, rather than
+force the user to assemble them using AND THEN, and then make the compiler work
+to disassemble them back into separate clauses so that decent messages can be
+output, but I can live with (and have implemented) this restriction (although we
+still allow multiple precondition and postcondition pragmas, as we always have).
+
+But I think for implementation defined aspects, this requirement should be
+relaxed. We lose nothing in portability by relaxing the requirement in this
+case, and we definitely gain in flexibility.
+
+We have encountered a number of situations, notably in connection with the
+Hi-Lite project, where the aspect notation is very helpful, but we need to be
+able to specify a particular aspect (e.g. Test_Case) multiple times.
+
+Yes, we can always put this under the -gnatX (language extensions allowed)
+switch, but I see no reason for the language enforcing this restriction for
+aspects it knows nothing about!
+
+****************************************************************
+
+From: Bob Duff
+Sent: Thursday, September 2, 2010 7:35 AM
+
+> But I think for implementation defined aspects, this requirement
+> should be relaxed. We lose nothing in portability by relaxing the
+> requirement in this case, and we definitely gain in flexibility.
+
+I agree 100%.
+
+More generally, whenever the RM allows implementation defined things, then the
+implementation should have completely free rein to define the semantics of those
+things.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, September 2, 2010 3:50 PM
+
+> But I think for implementation defined aspects, this requirement
+> should be relaxed. We lose nothing in portability by relaxing the
+> requirement in this case, and we definitely gain in flexibility.
+
+This is really the wrong description. The basic model of aspects, as described
+in 13.1, is that each one can only be specified once. The wording in the
+standard unfortunately ties that to *how* it is specified, but that's really the
+wrong model. I'd be in favor of eliminating the last sentences of 13.1(9) and
+13.1(9.1/1) and replacing them with a blanket rule that an aspect can only be
+specified once (in any way). The method of specification is irrelevant.
+
+That's important as an aspect is a property of an entity, never a property of a
+view of an entity: an aspect always has the same value for every view of an
+entity.
+
+One of the advantages of a blanket rule on aspects is that it gives you what you
+want. There is nothing wrong with an implementation-defined characteristic (that
+is *not* an aspect per-se) being specified in an aspect specifiication. (There
+is no language purity cop passing on the language correctness of
+implementation-defined stuff!!) In that case, the rules for aspects (such as
+only one definition) don't necessarily apply.
+
+So I am suggesting removing the last sentence of 13.1(9) and 13.1(9.1/1) (and
+the corresponding wording in AI05-0183-1), and adding a new paragraph after
+13.1(9.1/1):
+
+It is illegal to directly specify an aspect of an entity (by any means) if there
+is another representation item, operational item, or aspect clause for the same
+aspect of the entity.
+
+We might also want to loosen the wording of AI05-0183-1 at bit (or maybe just a
+"to-be-honest" AARM note) to make it clear that implementations can use this
+syntax for implementation-defined things that aren't quite aspects (that is,
+they might allow multiple versions, they might be view dependent, etc.). (I
+would not be surprised if we wanted to do that at some point down the road in
+the Standard.)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, September 2, 2010 5:44 PM
+
+> We might also want to loosen the wording of AI05-0183-1 at bit (or
+> maybe just a "to-be-honest" AARM note) to make it clear that
+> implementations can use this syntax for implementation-defined things
+> that aren't quite aspects (that is, they might allow multiple
+> versions, they might be view dependent, etc.). (I would not be
+> surprised if we wanted to do that at some point down the road in the
+> Standard.)
+
+Right, all I am arguing for is freedom in implementation defined aspects. after
+all you can't make legitimate ACATS tests for such attributes anyway, so any
+restrictions would be untestable :-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, September 10, 2010 10:59 AM
+
+Revisiting the delayed evaluation issue.
+
+Clearly read/write/input/output HAVE to be delayed, otherwise they would be
+useless, since in 100% of the cases you will reference entities not declared
+yet.
+
+I think we all agree that it is really useful to delay precondition,
+postcondition in the same way. Note that the GNAT pragmas have always
+implemented this delay.
+
+Invariant really has to be delayed too, since often the expression will be a
+function call referencing the type to which the aspect is attached.
+
+So we have a bunch of cases where the full delay is required (no visibility
+analysis till the end of the declarative part).
+
+So revisiting the issue of other aspects, e.g.
+
+ type R is range 1 .. 10 with
+ Size => S'Size;
+
+Originally I liked the idea that this was equivalent
+to:
+
+ type R is range 1 .. 10;
+ for R'Size use S'Size;
+
+Since that is easy to explain, and does not cause any surprises.
+
+But Tuck argues that there will be too many cases where this causes premature
+freezing, so instead he argues for a preanalysis (like default expressions) to
+establish visibility at the point of declaration, but then leave the full
+analysis (and freezing) to the end of the declarative part.
+
+Randy argues that it is too confusing to have different rules.
+
+I must say I am inclined to change my mind, if we can't have the simple
+equivalence I first suggested, I think I would prefer uniformity. In practice
+for something like Size, it will never make a difference. Yes you can create
+examples where it does make a difference but these will be very rare in
+practice, and in any case we have some of those same situations with
+precondition/postcondition or invariant delays.
+
+The AI is written delaying everything, and I think that's probably the better
+choice, and is also the path of least resistance (no change needed).
+
+If we go this route, it will be trivial to change the GNAT implementation to
+conform to this (just a matter of removing the boolean variable Delay_Required,
+since it will now always be True :-))
+
+Randy has also argued for making the situation where the visibility changes
+illegal, e.g. the following would be illegal:
+
+ type R is range 1 .. 512;
+
+ declare
+ type S is range 1 .. 10 with
+ Size => R'Size;
+
+ type R is range 1 .. 511;
+
+ begin
+ ...
+
+I don't mind having or suggesting a warning in this situation (though at least
+for us this is extremely difficult to do, yes its conceptually easy to do the
+analysis twice and see if it changed, but it would have a big impact on the
+details of visibility processing).
+
+I do mind VERY MUCH making this illegal, it seems a really bad idea that you
+write a declare block with no global references, and it's legal, and then you
+add a global declaration to some withed package miles away and suddenly:
+
+a) the declare block is illegal
+
+b) the only way to defend against it is to change
+ names (fiddling till you find something that does
+ not happen to be used globally now, and hoping
+ it won't be used later).
+
+So I am really opposed to trying to forge illegality rules here. Yes, you can
+construct confusing cases like the one above (which can be made more confusing
+by adding hundreds of declarations before the second declaration of R), but in
+practice such cases will be very rare.
+
+****************************************************************
+
From: Christoph Grein
Sent: Tuesday, September 28, 2010 2:33 AM
@@ -4678,8 +5195,363 @@
****************************************************************
+From: Randy Brukardt
+Sent: Tuesday, February 1, 2010 5:03 PM
+
+John has been complaining privately about the use of aspects in the Queue
+containers. This has led us (John and I, at least) to wonder about whether the
+syntax for aspects is ideal. But this is something that the entire group ought
+to consider.
+
+Here is an excerpt of our conversation.
+
+The declaration in question:
+
+ protected type Queue
+ (Ceiling: System.Any_Priority := Default_Ceiling)
+ with Priority => Ceiling is
+ new Queue_Interfaces.Queue with
+
+[This is formatted as suggested by the RM layout (that is, by Tucker's original
+intention) and not some of the later layouts that we've seen.]
+
+John writes (in part):
+
+> My other concern which I have voiced before is that we are using "with"
+> rather a lot. Mostly it deosn't matter but here we have several
+> different uses close by
+>
+> with for the aspect
+> with for the declaration list giving the entries etc
+>
+> and then glancing up the page we have
+>
+> with function
+> with package
+>
+> and good old fashioned
+>
+> with System
+>
+> I can cope with these exisiting ones because they are disjoint. But
+> the "with" aspect occuring together with the "with" introducing the
+> entries for me is a with too far (maybe I should say a with too
+> close).
+>
+> For me the confusion goes away if we use pragmas in contexts such as
+> this.
+
+Randy:
+
+That fixes nothing. We're not defining any new pragmas for these sorts of
+things, so sooner or later you'll have to use an aspect in these contexts. If
+there is something wrong with the aspect syntax, we need to make it right, and
+right away while we still can.
+
+I wonder if the problem is overuse of the keyword "with". That has been
+bothering me for a while; it is especially bad for extensions where "with" for
+the extension and "with" for the aspects are in close proximity.
+
+I wonder if we should consider a different keyword. "use" comes to mind,
+especially as that is what is used in the existing attribute clauses. How does
+this look:
+
+ protected type Queue
+ (Capacity : Count_Type := Default_Capacity;
+ Ceiling: System.Any_Priority := Default_Ceiling)
+ use Priority => Ceiling is
+ new Queue_Interfaces.Queue with
+
+I'll note that the keyword really ought to be "using", and the layout is
+backwards:
+
+ using Ceiling for Priority is
+
+but that seems too radical, having a new keyword (and difficult to parse, given
+that the aspect name goes last in this syntax).
+
+Equally radical would be to actually have a keyword "aspects":
+
+ aspects Priority => Ceiling is
+
+or
+
+ with aspects Priority => Ceiling is [although this latter seems to be reintroducing the with problem.]
+
+or
+
+ using aspects Priority => Ceiling is [nah, too wordy.]
+
+"properties" is another possible keyword:
+
+ protected type Queue
+ (Capacity : Count_Type := Default_Capacity;
+ Ceiling: System.Any_Priority := Default_Ceiling)
+ properties Priority => Ceiling is
+ new Queue_Interfaces.Queue with
+
+Any other ideas? Whatever is chosen has to work for subprograms as well.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, February 1, 2010 9:39 PM
+
+> protected type Queue
+> (Ceiling: System.Any_Priority := Default_Ceiling)
+> with Priority => Ceiling is
+> new Queue_Interfaces.Queue with
+
+> protected type Queue
+> (Capacity : Count_Type := Default_Capacity;
+> Ceiling: System.Any_Priority := Default_Ceiling)
+> properties Priority => Ceiling is
+> new Queue_Interfaces.Queue with
+>
+> Any other ideas? Whatever is chosen has to work for subprograms as well.
+
+I like the use of WITH, but I think it is much better with a different
+layout:
+
+>> protected type Queue
+>> (Ceiling: System.Any_Priority := Default_Ceiling) with
+>> Priority => Ceiling is
+>> new Queue_Interfaces.Queue with
+
+I don't like the with at the start of the line.
+
+Also this is somewhat of a worst case, and I don't think it is helpful to argue
+from worst cases.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 2, 2010 8:55 AM
+
+> ... I like the use of WITH, but I think it is much better with a
+> different
+> layout:
+>
+>>> protected type Queue
+>>> (Ceiling: System.Any_Priority := Default_Ceiling) with Priority =>
+>>> Ceiling is new Queue_Interfaces.Queue with
+>
+> I don't like the with at the start of the line.
+
+Well I am just the opposite. I find the "dangling" with very confusing, as it
+is just where I often the see the "with" used for type extension. I much
+prefer:
+
+ protected type Queue
+ (...)
+ with Priority => Ceiling,
+ Cool => Beans is
+ new Queue_Interfaces.Queue with
+ ...
+ end Queue;
+
+> Also this is somewhat of a worst case, and I don't think it is helpful
+> to argue from worst cases.
+
+I suppose, but this is a "normal" case for any task or protected type extension.
+There isn't anything especially bad about Queue.
+
+Note that record and private type extension also will end up with two "with"s if
+they have aspects.
+
+I happen to like "with" (as must be apparent), but I could live with(?) other
+keywords if they sounded reasonable. If we look at the simpler cases, such as:
+
+ procedure P(...)
+ with Pre => X < Y;
+
+the problem with "use" is that it is legal following a procedure declaration,
+meaning that if you leave out the ";" by mistake, you could end up with
+something like this:
+
+ procedure P(...) -- forgot the ";"
+ use Pre;
+ ...
+
+vs.
+ procedure P(...)
+ use Pre => X < Y;
+
+It also doesn't read quite as well.
+
+Other possibilities:
+
+ procedure P(...)
+ and Pre => X < Y,
+ Post => P'Result > Y;
+
+ procedure P(...)
+ while Pre => X < Y,
+ Post => P'Result > Y;
+
+ procedure P(...)
+ when Pre => X < Y,
+ Post => P'Result > Y;
+
+ procedure P(...)
+ for Pre => X < Y,
+ Post => P'Result > Y;
+
+Of the above, I suppose "and" and "for" aren't too hideous, but "with" still
+seems more natural. And of course "and" is already used in type extension, and
+"for" is legal just like "use" in a declare part, so a missing ";" will produce
+the same confusion.
+
+If I had to choose, "with" and "and" would be my two choices, in that order.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, February 2, 2010 9:12 AM
+
+A very minor issue here is that the new release of GNAT fully supports aspects
+using the WITH syntax, that means we will in practice likely continue to support
+it if it is changed (under the language extension flag).
+
+I don't think that should be decisive, but it does mean that we need a strong
+case and a strong consensus to make the change.
+
+I must say, never mind this issue, that I don't like USE as a replacement,
+because USE does appear in declarations freely right now.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Wednesday, February 2, 2010 10:23 AM
+
+> Other possibilities:
+> ...
+>
+> procedure P(...)
+> for Pre => X < Y,
+> Post => P'Result > Y;
+
+I don't know if this possibility has been considered:
+
+ procedure P(...)
+ for Pre use X < Y,
+ for Post use P'Result > Y;
+
+It would be the closest to the existing attribute definition syntax.
+
+I agree with John that the "with" syntax for aspects, is unnecessarily confusing
+with the "with" for type extension. And it seems unnecessarily different from
+attribute definition clauses.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Wednesday, February 2, 2010 12:36 PM
+
+>> Other possibilities:
+>> ...
+>>
+>> procedure P(...)
+>> for Pre => X < Y,
+>> Post => P'Result > Y;
+>
+> I don't know if this possibility has been considered:
+>
+> procedure P(...)
+> for Pre use X < Y,
+> for Post use P'Result > Y;
+>
+> It would be the closest to the existing attribute definition syntax.
+>
+Hmm... since this is mostly aesthetical, I'd like some kind of separator before the specification of aspects.
+
+"with" is not bad, although I share the concern it might be confusing.
+But I can live with it.
+"and" reads natural, but is not in its normal usage. Oh well, you have it for
+interface inheritance too. So we would have: type D and <aspects> is new T and
+I1; not much better...
+
+"select" could be used...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 2, 2010 7:28 PM
+
+> I don't know if this possibility has been considered:
+>
+> procedure P(...)
+> for Pre use X < Y,
+> for Post use P'Result > Y;
+>
+> It would be the closest to the existing attribute definition syntax.
+
+This doesn't seem to address Robert's concern about similarity to existing constructs in lists of declarations.
+
+He thinks "use" isn't acceptable (by itself) because use clauses might appear; there isn't much difference between:
+
+ procedure P (A : Natural)
+ use Pre => A > 10;
+
+and
+
+ procedure P (A : Natural);
+ use Pack;
+
+The difference here to the reader is really just a semicolon (until the => is
+encountered, but that's pretty late).
+
+A similar problem would occur with your proposal:
+
+ procedure P(A : Natural)
+ for Pre use A > 10;
+
+and
+
+ procedure P (A : Natural);
+ for P'Address use Foo;
+
+Here the difference is a semicolon and an attribute reference. A bit better, but
+not much.
+
+I'd also think that there would be confusion as to the proper syntax. I'd expect
+people to often write:
+
+ Obj : Small_Int
+ for Obj'Size use 8;
+
+by accident. There is some value to it being different.
+
+> I agree with John that the "with" syntax for aspects, is unnecessarily
+> confusing with the "with" for type extension.
+> And it seems unnecessarily different from attribute definition
+> clauses.
+
+I'm fairly convinced that if we do change this, we need to do so by using a
+totally new keyword. Most of the existing ones have been used enough.
+
+Well, we could use "some" for this, it's wildly underused:
+
+ procedure P(A : Natural)
+ some Pre => A > 10;
+
+(OK, I'm kidding.) "accept", "do", and "select" are all in this category, too,
+but none make much sense.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Thursday, February 3, 2010 3:25 AM
+
+> (OK, I'm kidding.) "accept", "do", and "select" are all in this
+> category, too, but none make much sense.
+
+and don't forget "until". Doesn't make sense either.
+
+****************************************************************
+
From: Tucker Taft
-Sent: Sunday, February 13, 2011 4:35 PM
+Sent: Sunday, February 13, 2010 4:35 PM
Here is a relatively minor update to AI-183 on aspect specifications. We now
allow "identifiers specific to an aspect" in an aspect specification (how's that
@@ -4696,7 +5568,7 @@
****************************************************************
From: Jean-Pierre Rosen
-Sent: Monday, February 14, 2011 2:19 AM
+Sent: Monday, February 14, 2010 2:19 AM
> We also allow aspect specifications on renaming declarations, but
> indicate there are no language-defined aspects that can be specified
@@ -4711,7 +5583,7 @@
****************************************************************
From: Tucker Taft
-Sent: Monday, February 14, 2011 8:51 AM
+Sent: Monday, February 14, 2010 8:51 AM
Oops, sorry about that. Once I get embroiled in wording, I always forget to go
back and read the summary/proposal!
@@ -4721,7 +5593,7 @@
****************************************************************
From: Randy Brukardt
-Sent: Monday, February 14, 2011 10:37 PM
+Sent: Monday, February 14, 2010 10:37 PM
The following paragraph is under Legality Rules:
@@ -4735,8 +5607,10 @@
Legality Rules.)
****************************************************************
+
+From: Tucker Taft
+Sent: Monday, February 14, 2010 11:03 PM
-[Randy's note: Mail from August and September probably goes at line 2799
-in this file.]
+Agreed, that does seem more like a Static Semantics rule.
****************************************************************
Questions? Ask the ACAA Technical Agent