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.
****************************************************************