!standard 3.3.1(10) 10-10-25 AI05-0229-1/01 !standard 3.3.1(21) !class Amendment 10-10-25 !status work item 10-10-25 !status received 10-10-25 !priority Medium !difficulty Easy !subject Specifiable aspects !summary (See proposal.) !problem The new aspect clauses (see AI05-0183-1) provide convinient syntax for specifying aspect values. We ought to be able to use that syntax to specify existing aspects as well as new ones. !proposal !wording [Author's note: I've no idea where the following wording belongs.] The following aspects may be used as an aspect_mark: - Each specifiable attribute may be specified by an attribute_definition_clause, as explained in 13.3, or by an aspect_specification, with the same semantics. - A representation pragma that has a single argument that is a local_name may be specified by an aspect_specification, with the entity being the local_name, the aspect_mark being the same as the pragma name. The aspect_definition is expected to be of type Boolean. The expression shall be static with value True. - Additional aspects that are neither attributes nor pragmas are defined throughout this International Standard. AARM Discussion: The following representation pragmas may also be specified using an aspect_specification: Asynchronous E.4.1(8) Atomic C.6(14) Atomic_Components C.6(14) Controlled 13.11.3(5) Discard_Names C.5(6) Independent C.6(14) Independent_Components C.6(14) Pack 13.2(5) Volatile C.6(14) Volatile_Components C.6(14) Unchecked_Union The following representation pragmas cannot be specified using an aspect_specification, because the pragma arguments wouldn't make sense as an aspect_definition: CPU ??? Convention B.1(28) Export B.1(28) Import B.1(28) End AARM Discussion. (Seems like the above should be part of AI05-0183-1. I can understand why you might want the stuff below in a separate AI.) Change "packing" to "Pack" in numerous (but not all) places. E.g. 9.10(1/3). Remove all wording for representation pragmas that says this pragma specifies so-and-so aspect: 13.2(5): 5 [A pragma Pack specifies the packing aspect of representation; ] {If Pack is specified, } the type (or the extension part) is said to be packed. For a type extension, the parent part is packed as for the parent type, and a pragma Pack causes packing only of the extension part. 13.11.3(5): 5 A pragma Controlled is a representation pragma[ that specifies the controlled aspect of representation]. B.3.3(4/2): 4/2 Unchecked_Union is a representation pragma[, specifying the unchecked union aspect of representation]. C.5(6): No changes needed for Discard_Names. C.6(14): No changes needed for Atomic, Atomic_Components, Independent, Independent_Components, Volatile, Volatile_Components. E.4.1(8): 8 A pragma Asynchronous is a representation pragma.[ When applied to a type, it specifies the type-related asynchronous aspect of the type.] Add Unchecked_Union to the index under "representation pragma". !discussion !ACATS test ACATS tests would be needed for this aspect. !appendix From: Bob Duff Sent: Monday, October 25, 2010 2:44 PM From the Valencia minutes: New Action Items ... Bob Duff ... AI to add wording to explain which non-attribute aspects can be specified via aspect clauses, and the exact semantics for such specification. (See discussion of AI05-0183-1.) Participate in the amendment subcommittee ... ---------------- Tucker would like to make a separate AI to handle changes to individual aspects. But add a general statement about specifiable attributes in this AI. Wording needs to be added to 13.1(9-9.1) to include aspect clauses (to prevent specifying one aspect in multiple ways). Tucker says that he tried to use some common wording in AI-139-2, 4.1.6. This would then be used to create an annex similar to the attribute one. We are electing Bob to do this new AI, using the AI05-0139-2 wording as a model. He will need to A,"fixA," the wording from AI05-0145-2 into this format. [Editor's note: I did this for the wording proposed for AI05-0146-1 and in these minutes for AI05-0153-1]. Randy explained the above privately: > We want the AI which defines which aspects can be specified with the > AI-183 to be separate from AI-183, because it is likely to be large > and it would obscure the more complex wording. OK. I've included some wording below. I think I may be misunderstanding what you want, because it's not all that large. If you have in mind rewriting all the rules for every sort of attribute_definition_clause, then, well... That's NUTS! If this job entails rewriting all of chap 13 (again!) plus a bunch of other stuff, then I think we should back off. It is REALLY not important to allow "Foo with Bar => Baz" when there's already a way to say it. > AI-139-2 defines a couple of aspects in a format that Tucker is > proposing be used for *all* specifiable aspects. You can use that as a > model (or AI-146 or AI-153-1 as I already modified them to use that same > format). OK, and as clarified by Tucker privately, some aspects are also attributes, some are also pragmas, and some are just aspects. > We expect that all specifable attributes will be usable as aspects in > aspect clauses in the same way as they can be used in attribute > clauses (that will reduce the needed wording). But we also need > wording for every pragma that can be used as an aspect: probably Pack, > the ones in C.6, Priority, CPU (which is new),... If CPU is new, we could get rid of the pragma, and just make it an aspect. The whole point of aspect_specifications (25 years too late) is to reduce the proliferation of pragmas, each with its own distinct rules. >... etc. Robert had suggested that Pack => False turn off packing (not >sure if that introduces new problems, it definitely would for Atomic). >You'll need to decide if that makes sense. I'm not sure I like the idea of Pack => False. It seems like a neat feature in isolation, but if it requires hard thinking about Atomic and friends, I'm not sure it's worth the trouble. ---------------- I've no idea where the following wording belongs. I'm still not sure exactly what's wanted, so I'm sending this trial baloon to see if it floats. The following aspects may be used as an aspect_mark: - Each specifiable attribute may be specified by an attribute_definition_clause, as explained in 13.3, or by an aspect_specification, with the same semantics. - A representation pragma that has a single argument that is a local_name may be specified by an aspect_specification, with the entity being the local_name, the aspect_mark being the same as the pragma name. The aspect_definition is expected to be of type Boolean. The expression shall be static with value True. - Additional aspects that are neither attributes nor pragmas are defined throughout this International Standard. AARM Discussion: The following representation pragmas may also be specified using an aspect_specification: Asynchronous E.4.1(8) Atomic C.6(14) Atomic_Components C.6(14) Controlled 13.11.3(5) Discard_Names C.5(6) Independent C.6(14) Independent_Components C.6(14) Pack 13.2(5) Volatile C.6(14) Volatile_Components C.6(14) Unchecked_Union The following representation pragmas cannot be specified using an aspect_specification, because the pragma arguments wouldn't make sense as an aspect_definition: CPU ??? Convention B.1(28) Export B.1(28) Import B.1(28) End AARM Discussion. (Seems like the above should be part of AI05-0183-1. I can understand why you might want the stuff below in a separate AI.) Change "packing" to "Pack" in numerous (but not all) places. E.g. 9.10(1/3). Remove all wording for representation pragmas that says this pragma specifies so-and-so aspect: 13.2(5): 5 [A pragma Pack specifies the packing aspect of representation; ] {If Pack is specified, } the type (or the extension part) is said to be packed. For a type extension, the parent part is packed as for the parent type, and a pragma Pack causes packing only of the extension part. 13.11.3(5): 5 A pragma Controlled is a representation pragma[ that specifies the controlled aspect of representation]. B.3.3(4/2): 4/2 Unchecked_Union is a representation pragma[, specifying the unchecked union aspect of representation]. C.5(6): No changes needed for Discard_Names. C.6(14): No changes needed for Atomic, Atomic_Components, Independent, Independent_Components, Volatile, Volatile_Components. E.4.1(8): 8 A pragma Asynchronous is a representation pragma.[ When applied to a type, it specifies the type-related asynchronous aspect of the type.] Add Unchecked_Union to the index under "representation pragma". **************************************************************** From: Tucker Taft Sent: Monday, October 25, 2010 3:10 PM I am interpreting the "[]" as deletions, rather than indicating as redundant. Also, I notice you eliminated the mention that the asynchronous aspect was "type-related." I think we want to preserve the distinction between type-related and subtype-specific aspects. That may affect the legality of specifying the aspect on a subtype declaration. So we should be careful about deleting phrases that include "type-related" or "subtype-specific" unless they show up elsewhere. **************************************************************** From: Bob Duff Sent: Monday, October 25, 2010 5:51 PM > I am interpreting the "[]" as deletions, rather than indicating as > redundant. Right. I get mixed up between {} and []. I think the convention for AI's is {} for insertions, [] for deletions, and Redundant[] for redundancies. The convention in the AARM is [] for redundancies. The convention in the RM is to have no such noise. Please correct me if I'm wrong. >...Also, I notice you eliminated > the mention that the asynchronous aspect was "type-related." So I guess it should be: E.4.1(8): 8 A pragma Asynchronous is a representation pragma.[ When applied to a type, it specifies the type-related asynchronous aspect of the type.] The Asynchronous aspect is type-related when applied to a type. **************************************************************** From: Randy Brukardt Sent: Monday, October 25, 2010 6:15 PM > Right. I get mixed up between {} and []. I think the convention for > AI's is {} for insertions, [] for deletions, and Redundant[] for > redundancies. The convention in the AARM is [] for redundancies. The > convention in the RM is to have no such noise. > > Please correct me if I'm wrong. That is exactly right. **************************************************************** From: Randy Brukardt Sent: Monday, October 25, 2010 6:42 PM ... > I've no idea where the following wording belongs. I'm still not sure > exactly what's wanted, so I'm sending this trial baloon to see if it > floats. I think it is pretty close. We also need text to introduce the "aspect annex" (the intent is that we will have an annex similar to the attribute one that shows all of the possible aspects). The actual annex will be automatically created somehow. CPU and Priority don't have local names, but they ought to be specifable as aspects. (At least, we ought to consider that!) I'm not sure that Unchecked_Union makes sense here (it's closer to pragma Convention than to the others on this list). I suspect it would be best with the pragmas to simply list the ones that are included (then we don't need to come up with a blanket rule that isn't really quite what we want). **************************************************************** From: Bob Duff Sent: Saturday, October 30, 2010 1:00 PM More info on AI05-0229-1, Specifiable aspects. I tried to study all the pragmas (from Annex L), and see if they make sense as "aspects". ---------------- To make sense as an aspect, the pragma has to be restricted to the scope of the entity. It has to have two parameters, the first is the entity, the second a name/expression of some type, which is then the type of the aspect. Or, if the second argument is an "identifier specific to a pragma", it could make sense if we invent "identifiers specific to an aspect". Tucker said he'd work on that. Or it could have just one parameter, the entity, and the type of the aspect is Boolean (True/False means the pragma is present/absent). ---------------- Boolean representation attributes already discussed: 3 pragma Asynchronous(local_name); - See E.4.1. 4 pragma Atomic(local_name); - See C.6. 5 pragma Atomic_Components(array_local_name); - See C.6. 7 pragma Controlled(first_subtype_local_name); - See 13.11.3. 9 pragma Discard_Names[([On => ] local_name)]; - See C.5. 14.1/3 pragma Independent(component_local_name); - See C.6. 14.2/3 pragma Independent_Components(local_name); - See C.6. 24 pragma Pack(first_subtype_local_name); - See 13.2. 38 pragma Volatile(local_name); - See C.6. 39 pragma Volatile_Components(array_local_name); - See C.6. 37.1/2 pragma Unchecked_Union (first_subtype_local_name); - See B.3.3. ---------------- More Boolean aspects: 2 pragma All_Calls_Remote[(library_unit_name)]; - See E.2.3. 12 pragma Elaborate_Body[(library_unit_name)]; - See 10.2.1. 15 pragma Inline(name {, name}); - See 6.3.2. 17 pragma Interrupt_Handler(handler_name); - See C.3.1. 21.1/2 pragma No_Return(procedure_local_name{, procedure_local_name}); - See 6.5.1. 25.2/2 pragma Preelaborable_Initialization(direct_name); - See 10.2.1. 26 pragma Preelaborate[(library_unit_name)]; - See 10.2.1. 28 pragma Pure[(library_unit_name)]; - See 10.2.1. 30 pragma Remote_Call_Interface[(library_unit_name)]; - See E.2.3. 31 pragma Remote_Types[(library_unit_name)]; - See E.2.2. 34 pragma Shared_Passive[(library_unit_name)]; - See E.2.1. ---------------- Non-Boolean aspects: 6 pragma Attach_Handler(handler_name, expression); - See C.3.1. -- Aspect type is Interrupts.Interrupt_ID. 8.1/3 pragma CPU (expression); - See D.16. -- Aspect type is System.Multiprocessors.CPU_Range. And this implicitly applies to outer task/prot. Or PROCEDURE! 18 pragma Interrupt_Priority[(expression)]; - See D.1. -- Aspect type is Integer. Does aspect have a default? 27 pragma Priority(expression); - See D.1. -- Aspect type is Integer. Require static in procedure? 29.1/2 pragma Relative_Deadline (relative_deadline_expression); - See D.2.6. -- Aspect type is Real_Time.Time_Span. 35 pragma Storage_Size(expression); - See 13.3. -- Aspect type is universal_integer? ---------------- "identifiers specific to an aspect": 8 pragma Convention([Convention =>] convention_identifier,[Entity =>] local_name); - See B.1. (except the parameters are backwards) 13.1/2 pragma Implemented(procedure_local_name, implementation_kind); - See 9.5. ---------------- Make no sense as aspects: 2.1/2 pragma Assert([Check =>] boolean_expression[, [Message =>] string_expression]); - See 11.4.2. 2.2/2 pragma Assertion_Policy(policy_identifier); - See 11.4.2. 8.2/2 pragma Detect_Blocking; - See H.5. 10 pragma Elaborate(library_unit_name{, library_unit_name}); - See 10.2.1. 11 pragma Elaborate_All(library_unit_name{, library_unit_name}); - See 10.2.1. 13 pragma Export( [Convention =>] convention_identifier, [Entity =>] local_name [, [External_Name =>] string_expression] [, [Link_Name =>] string_expression]); - See B.1. 14 pragma Import( [Convention =>] convention_identifier, [Entity =>] local_name [, [External_Name =>] string_expression] [, [Link_Name =>] string_expression]); - See B.1. 16 pragma Inspection_Point[(object_name {, object_name})]; - See H.3.2. 19 pragma Linker_Options(string_expression); - See B.1. 20 pragma List(identifier); - See 2.8. 21 pragma Locking_Policy(policy_identifier); - See D.3. 22 pragma Normalize_Scalars; - See H.1. 23 pragma Optimize(identifier); - See 2.8. 25 pragma Page; - See 2.8. 25.1/2 pragma Partition_Elaboration_Policy (policy_identifier); - See H.6. 27.1/2 pragma Priority_Specific_Dispatching ( policy_identifier, first_priority_expression, last_priority_expression); - See D.2.2. 27.2/2 pragma Profile (profile_identifier {, profile_pragma_argument_association}); - See D.13. 29 pragma Queuing_Policy(policy_identifier); - See D.4. 32 pragma Restrictions(restriction{, restriction}); - See 13.12. 33 pragma Reviewable; - See H.3.1. 36 pragma Suppress(identifier); - See 11.5. 37 pragma Task_Dispatching_Policy(policy_identifier); - See D.2.2. 37.2/2 pragma Unsuppress(identifier); - See 11.5. ---------------- **************************************************************** From: Robert Dewar Sent: Saturday, October 30, 2010 1:12 PM > More info on AI05-0229-1, Specifiable aspects. > I tried to study all the pragmas (from Annex L), and see if they make > sense as "aspects". > 25.2/2 pragma Preelaborable_Initialization(direct_name); - See 10.2.1. > > 26 pragma Preelaborate[(library_unit_name)]; - See 10.2.1. > > 28 pragma Pure[(library_unit_name)]; - See 10.2.1. > > 30 pragma Remote_Call_Interface[(library_unit_name)]; - See E.2.3. > > 31 pragma Remote_Types[(library_unit_name)]; - See E.2.2. > > 34 pragma Shared_Passive[(library_unit_name)]; - See E.2.1. The library unit ones make no sense to me, it is obviously inferior to have these at the end of the unit instead of the start as wouldl be forced by use of aspects. Just for reference, the current GNAT list is: > Aspect_Address, > Aspect_Alignment, > Aspect_Bit_Order, > Aspect_Component_Size, > Aspect_Dynamic_Predicate, > Aspect_External_Tag, > Aspect_Input, > Aspect_Invariant, > Aspect_Machine_Radix, > Aspect_Object_Size, -- GNAT > Aspect_Output, > Aspect_Post, > Aspect_Pre, > Aspect_Predicate, -- GNAT > Aspect_Read, > Aspect_Size, > Aspect_Static_Predicate, > Aspect_Storage_Pool, > Aspect_Storage_Size, > Aspect_Stream_Size, > Aspect_Suppress, > Aspect_Unsuppress, > Aspect_Value_Size, -- GNAT > Aspect_Warnings, > Aspect_Write, > > -- Remaining aspects have a static boolean value that turns the aspect > -- on or off. They all correspond to pragmas, and the flag Aspect_Cancel > -- is set on the pragma if the corresponding aspect is False. > > Aspect_Ada_2005, -- GNAT > Aspect_Ada_2012, -- GNAT > Aspect_Atomic, > Aspect_Atomic_Components, > Aspect_Discard_Names, > Aspect_Favor_Top_Level, -- GNAT > Aspect_Inline, > Aspect_Inline_Always, -- GNAT > Aspect_No_Return, > Aspect_Pack, > Aspect_Persistent_BSS, -- GNAT > Aspect_Preelaborable_Initialization, > Aspect_Pure_Function, -- GNAT > Aspect_Shared, -- GNAT (equivalent to Atomic) > Aspect_Suppress_Debug_Info, -- GNAT > Aspect_Unchecked_Union, > Aspect_Universal_Aliasing, -- GNAT > Aspect_Unmodified, -- GNAT > Aspect_Unreferenced, -- GNAT > Aspect_Unreferenced_Objects, -- GNAT > Aspect_Volatile, > Aspect_Volatile_Components); **************************************************************** From: Bob Duff Sent: Saturday, October 30, 2010 6:17 PM > The library unit ones make no sense to me, it is obviously inferior to > have these at the end of the unit instead of the start as wouldl be > forced by use of aspects. I wonder if you implemented the right syntax, as specified by the latest version of AI-183. It's something like package P with Elaborate_Body => True is ... end P; This stuff is a moving target -- we keep changing various aspect names, etc. > Just for reference, the current GNAT list is: I haven't had time to compare your list to mine. All I know is, there seems to be pressure from everyone to make everything under the sun into an "aspect". I've no objection to that when it's easy, but a lot of these pragmas have all kinds of strange warts that require thinking about -- and RM wording -- that I'd like to avoid. My previous e-mail is an attempt to list out all pragmas that are remotely possible as aspects. **************************************************************** From: Robert Dewar Sent: Saturday, October 30, 2010 6:32 PM > I wonder if you implemented the right syntax, as specified by the > latest version of AI-183. It's something like > > package P with Elaborate_Body => True is > ... > end P; No, that's new, but why it is somehow preferable to package P is pragma Elaborate_Body; ... end P; when it is more tokens beats me, well we will eventually get these unimportant ones picked up when we figure what they are. This particular one is annoying since it is a special case (no semicolon after the aspect list). **************************************************************** From: Robert Dewar Sent: Monday, November 1, 2010 10:07 AM I think it is a good idea to have aspects for library unit pragmas, since it is always nicer to do things with proper syntax than pragmas when the result has significant semantic impact, so I prefer package X with Pure is to package X is pragma Pure; BUT, if we allow a Boolean parameter package X with Pure => True is ... then we need special rules, we can't delay the evaluation of True until X is frozen, so I think for such pragmas we shouldn't delay the evaluation of the expression! Actually, I would suggest that, assuming we keep the boolean expression for the boolean cases, with the possibility of False meaning, forget about the aspect entirely (remove the awkward cancellation semantics for the derived type case), then I think we should evaluate the boolean parameter immediately always. It is just silly to allow type R is array ... with Packed => True; ... True : Boolean := False; and if you are using this in a reasonable way to parametrize whether R should be packed, then it is perfectly reasonable for the boolean case to say that you refer to a previously set configuration, something like type R is array ... with Packed => Pack_If_Space_Optimizing; where Pack_If_Space_Optimizing is some global constant (off topic, I have often thought it would be useful to be able to define such global constants in the configuration pragma file, to avoid the need for a million with's :-)) **************************************************************** From: Tucker Taft Sent: Monday, November 1, 2010 10:34 AM I think we still want to defer resolution of pragmas that apply to packages. We had proposed the notion of a Package_Invariant at one point. That would almost certainly be an expression that would be boolean, and would involve calling a function declared later inside the package. So I am not sure I see the value nor the need to have different rules for aspects that apply to packages, nor for aspects that happen to be boolean. **************************************************************** From: Robert Dewar Sent: Monday, November 1, 2010 11:03 AM > I think we still want to defer resolution of pragmas that apply to > packages. We had proposed the notion of a Package_Invariant at one > point. That would almost certainly be an expression that would be > boolean, and would involve calling a function declared later inside > the package. So I am not sure I see the value nor the need to have > different rules for aspects that apply to packages, nor for aspects > that happen to be boolean. Well this is a case where the compiler is totally unprepared to deal with the equivalent of a pragma Pure appearing at the end of the package. This would be a major earthquake. We check the status of such things as we analyze the declarations of the package, anything else would be huge extra work for almost NO gain, since for something like Pure, being able to defer whether the package is Pure till the end of the package is pretty absurd. Also, how about package P with Pure => Pure_OK is ... Pure_OK : constant Boolean := False; ... end; Now we have the anomoly that if the package is pure, then the declaration is illegal, and cannot affect the legality of the rest of the package, but if it is not pure, then the declaration is OK, and since it indeed False and the package is not Pure. My suggestion applies ONLY to aspects where we require a static Boolean value (e.g. Pack, Pure etc). Of course it does not apply to any situation where we have a general boolean expression. The cases of static boolean values being required for binary aspects that are on (True) or off (False) are really are quite different. If we allow an expression here at all is a matter of debate, if we allow it, allowing False is a matter of debate. But surely delaying the evaluation in such a case is NOT useful, it allows only stupid useless tests at the expense (if applied to pragmas that normally could not be themselves delayed) of huge extra work in the compiler. **************************************************************** From: John Barnes Sent: Monday, November 1, 2010 11:04 AM I haven't really been following this because of being poorly. But I think pragma Pure is fine as it is; I wouldn't want to write. package Ada with Pure is end Ada; Horrid. **************************************************************** From: Robert Dewar Sent: Monday, November 1, 2010 11:11 AM For me package Ada with Pure => True is end Ada; is better than package Ada is pragma Pure; end Ada; because I don't like pragmas having a big effect on legality like this. Better done with syntax. Note the pragma is still there, so if this is just asthetics on your part (note for me there is a real principle about bad pragmas not just syntax aesthetics), then you can still use the pragma if you want. **************************************************************** From: Tucker Taft Sent: Monday, November 1, 2010 11:54 AM I now understand your concern about Pure. I don't particularly like having to make an exception for this case, but if we make one, it will need to be clearly defined. We already require static values for many aspects, but deferring most to the freezing point is no hardship, since that is where the rep-clause would have taken affect. So we will need some clear distinction for these particular aspects for which we won't allow deferral. Perhaps what you are suggesting is that although it is no hardship, it is also no great advantage, to permit deferral of Boolean aspects that require a static value. Obviously if you had omitted the "=> True" you wouldn't be deferring the determination, so perhaps we can use that as a distinction. Namely if the aspect is Boolean, and it has to be given statically, then in addition, we say that the static expression is resolved and evaluated at the point of the aspect specification. My one bit of discomfort here is for things such as pragma Pack where we might want to decide it based on something like the 'Size of something else. E.g: type Arr_Of_Elem is array(...) of Elem with Pack => Elem'Size <= System.Storage_Unit/2; This use of 'Size will cause freezing of Elem, so we might like it to be deferred as long as possible. So perhaps we should limit it further to aspects that require a static Boolean value and that apply to packages or generic packages. **************************************************************** From: Tucker Taft Sent: Monday, November 1, 2010 12:29 PM Coming up with some general rule is not really necessary. We have already allowed particular aspects to have their own rules. So aspects Pure and Preelaborated, and perhaps the other various "categorization" aspects like Remote_Types, should have this rule that they require a static expression which is resolved and evaluated at the point of the aspect specification. This would allow use of constants declared in "with"ed packages, but nothing local in the package. The rule that the resolution would be the same if it were deferred to after the end of the package would still seem to be useful to avoid confusion. **************************************************************** From: Robert Dewar Sent: Monday, November 1, 2010 4:38 PM I disagree in this case, simply not worth the effort and would require a lot of extra mechanism. Why not just decide that the whole business of delayed resolution and checking it is plain silly for these static boolean predicates, the only arguments that make sense are True (9x% of the cases) Some boolean static exptression depending on previously declared stuff (very small % of remaining cases). I really think that worrying about having type x is array (0 .. 31) of Boolean with Pack => True; ... True : Boolean := False; being required to generate a message is not worth any discussion, let alone implementation effort. It's so much cleaner to say that these aspects are analyzed and evaluated at the time of the aspect appearing. If it evaluates to True, the aspect is active, if it is False, then the aspect is entirely ignored, end of story. **************************************************************** From: Robert Dewar Sent: Monday, November 1, 2010 4:41 PM > Perhaps what you are suggesting > is that although it is no hardship, it is also no great advantage, to > permit deferral of Boolean aspects that require a static value. > Obviously if you had omitted the "=> True" > you wouldn't be deferring the determination, so perhaps we can use > that as a distinction. > Namely if the aspect is Boolean, and > it has to be given statically, then in addition, we say that the > static expression is resolved and evaluated at the point of the aspect > specification. Right, seems reasonable > My one bit of discomfort here is for things such as pragma Pack where > we might want to decide it based on something like the 'Size of > something else. E.g: > > type Arr_Of_Elem is array(...) of Elem > with Pack => Elem'Size<= System.Storage_Unit/2; > > This use of 'Size will cause freezing of Elem, so we might like it to > be deferred as long as possible. Perhaps so, at this stage I have all the (quite complex) mechanism in place for doing this, so I am cool either way. I actually find the above example fairly convincing :-) > So perhaps we should limit it further to aspects that require a static > Boolean value and that apply to packages or generic packages. That seems reasonable to me (in fact it is exactly what I have implemented for now :-)) Have we definely agreed to avoid the cancellation mechanism for derived types (that will allow me to remove quite a bit of rather messy implementation junk). **************************************************************** From: Tucker Taft Sent: Monday, November 1, 2010 4:50 PM > Have we definely agreed to avoid the cancellation mechanism for > derived types (that will allow me to remove quite a bit of rather > messy implementation junk). I believe we disallowed turning off certain things on derived types. In particular, the various aspects relating to shared variables cannot be turned off (e.g. Atomic, Atomic_Components, ...). I forget whether we extended that to cover any other aspects, such as Pack. **************************************************************** From: Robert Dewar Sent: Monday, November 1, 2010 4:53 PM My recommendation is simply to say that if an aspect is set to False, then it has no effect, i.e. it is as though it were not present at all, and the fact that this means that we are NOT trying to cancel any derived type stuff falls out from this. I don't like going through things one aspect at a time to figure out what the effect is. After all we never had this capability before, and I can't remember anyone ever complaining :-) **************************************************************** From: Tucker Taft Sent: Monday, November 1, 2010 5:47 PM > My recommendation is simply to say that if an aspect is set to False, > then it has no effect, i.e. it is as though it were not present at > all, and the fact that this means that we are NOT trying to cancel any > derived type stuff falls out from this. That sounds a bit confusing to me. Why would a boolean-valued aspect have this non-overriding behavior for just one of its values, while a non-boolean-valued aspect would have overriding behavior for all of its possible values? > I don't like going through things one aspect at a time to figure out > what the effect is. After all we never had this capability before, and > I can't remember anyone ever complaining :-) I think you will need a better argument than this to convince the rest of the ARG. ;-) **************************************************************** From: Robert Dewar Sent: Monday, November 1, 2010 6:10 AM Now I am confused, initially I was in favor of cancellation semantics in all cases for derived types, and that is what I have implemented. Now you seem to say the ARG does not want that, I don't really care that much, but it would be nice if people could make up their minds. And I do think it would be best to avoid a lot of special case rules implementing a feature that has never been used. The reason I think the boolean valued stuff is different is that this is NOT providing a value to be used, quite different from size or invariant. It is simply indicating whether the aspect is active or not. Perhaps the whole business of allowing => True at all is wrong, just insist on no parameter at all for these cases, after the whole business of cancellation came up as a surprise when I first raised it :-) **************************************************************** From: John Barnes Sent: Tuesday, November 2, 2010 4:40 AM ... > For me > > package Ada with Pure => True is > end Ada; That's awful. It has that gruesome juxtaposition "is end". ... > Note the pragma is still there, so if this is just asthetics on your > part (note for me there is a real principle about bad pragmas not just > syntax aesthetics), then you can still use the pragma if you want. I am aware that I can still use the pragmas and I would for Pure etc but what I really want to know is are you thinking of going all the way through the RM changing existing text to get rid of the use of pragmas such as Pure? Don't get me wrong, I think that the introduction of these aspect things is a wonderful idea. Pre and postconditions would be hopeless without. But I don't think they are appropriate for Pure etc. You also have to remember that people read each other's programs and it is confusing if different people use gratuitously different styles. **************************************************************** From: Brad Moore Sent: Tuesday, November 2, 2010 10:00 AM > That's awful. It has that gruesome juxtaposition "is end". What if package aspect specifications occurred immediately after the "is" instead of before, and they allowed an extra aspect mark to appear to the left of the with, and the with is optional and only needed if more than one aspect was named. The idea is that programmers would have the flexibility to choose a style that best fits the combination of pragmas they wanted to use. Then I could (and would) write; package Ada is Pure end Ada; This reads very nicely I think. For a different pragma such as Remote_Types, I would use the other format. package Ada is with Remote_Types end Ada; If I wanted to specify both, I would write package Ada is Pure with Remote_Types end Ada; **************************************************************** From: Robert Dewar Sent: Tuesday, November 2, 2010 10:27 AM >>> For me >>> >>> package Ada with Pure => True is >>> end Ada; >>> >> That's awful. It has that gruesome juxtaposition "is end". This makes ZERO sense to me, the aspect stuff does not change that. That "gruesome juxtaposition" has been in Ada since the very beginning, you have always been able to say package Ada is end Ada; that's normal standard syntax, so John's adverse reactions to it are interesting but totally irrelevant to this discussion! > What if package aspect specifications occurred immediately after the > "is" instead of before, and they allowed an extra aspect mark to > appear to the left of the with, and the with is optional and only > needed if more than one aspect was named. > > The idea is that programmers would have the flexibility to choose a > style that best fits the combination of pragmas they wanted to use. > > Then I could (and would) write; > > package Ada is Pure > end Ada; Messy to allow this, given that package Ada is Pure : Integer; end Ada; is quite fine. I really think we should keep the WITH for all aspect specifications, there is no point in creating special syntax for this one case! > This reads very nicely I think. I really do not like the Pure just sitting in the declarative part, it seems odd to me, and even odder is package Ada is Pure Pure : Integer; end Ada; Here we have two identifiers occurring together with no punctuation between them, to see how odd it can become look at package Ada is Pure XYZ, ABC : Integer; end Ada Now it is just the lack of a comma between Pure and XYZ that makes Pure an aspect rather than an Integer variable. You can't seriously think this is a good idea when you see this example :-) > For a different pragma such as Remote_Types, I would use the other > format. > > package Ada is with Remote_Types > end Ada; > > If I wanted to specify both, I would write > > package Ada is Pure > with Remote_Types > > end Ada; Getting even worse in my view, this mixing of two syntaxes is really unpleasant. **************************************************************** From: Robert Dewar Sent: Tuesday, November 2, 2010 11:44 AM To me this syntax looks fine: > 1. pragma Ada_2012; > 2. package aspectpu with Pure is > 3. X : Integer; > | > >>> declaration of variable not allowed in pure unit > > 4. end; **************************************************************** From: John Barnes Sent: Wednesday, November 3, 2010 3:19 AM > This makes ZERO sense to me, the aspect stuff does not change that. > That "gruesome juxtaposition" has been in Ada since the very > beginning, you have always been able to say > > package Ada is > end Ada; > > that's normal standard syntax, so John's adverse reactions to it are > interesting but totally irrelevant to this discussion! I have always hated that and would like the option of saying just package Ada; just as we can say task T; But as you say that is another matter. But it is not irrelevant in the sense that I am against further uglification I would advise against too much choice. Just stick to the with and omit => True. And the elderly can use pragma Pure. But what I really want to know is are we intending to change all the existing uses of pragmas such as Pure to the new syntax? **************************************************************** From: Robert Dewar Sent: Wednesday, November 3, 2010 4:16 AM > But what I really want to know is are we intending to change all the > existing uses of pragmas such as Pure to the new syntax? That's a coding style question, not a language question. Of course the language will retain the pragmas (indeed in GNAT, we have introduced new pragmas such as Invariant and Predicate to take adavtange of these new features in other than Ada 2012 mode). No one is suggesting the obviously unacceptable step of removing the pragmas, and if we did it would be a waste of time, since implementations would leave them in anyway. Note also that the pragmas are a bit more flexible, e.g. Size can appear in the private part, which has methodological and functional implications. **************************************************************** From: Bob Duff Sent: Wednesday, November 3, 2010 8:51 PM > But what I really want to know is are we intending to change all the > existing uses of pragmas such as Pure to the new syntax? You mean existing pragmas Pure in the various language-defined packages in the RM? I've never heard anybody suggest changing those, and I am opposed to changing those (lots of work, no benefit). **************************************************************** From: John Barnes Sent: Thursday, November 4, 2010 3:04 AM > You mean existing pragmas Pure in the various language-defined > packages in the RM? I've never heard anybody suggest changing those, > and I am opposed to changing those (lots of work, no benefit). Good. So all this discussion about with Pure is almost academic. I will ignore it. John **************************************************************** From: Bob Duff Sent: Thursday, November 4, 2010 7:37 AM > Don't get me wrong, I think that the introduction of these aspect > things is a wonderful idea. Pre and postconditions would be hopeless > without. But I don't think they are appropriate for Pure etc. > > You also have to remember that people read each other's programs and > it is confusing if different people use gratuitously different styles. John, I am also somewhat uncomfortable with the push to make everything under the sun into an "aspect". I agree with your "gratuitously different styles" comment. And I think it's a lot of work. (Work that I have apparently been "volunteered" to do...) My list of pragmas was not intended as an endorsement -- I was told to come up with a list of pragmas that might make sense as aspects. The ARG has not yet discussed this list, so there is no official decision that Pure is an aspect. My impression is that everybody on ARG thinks it should be, except you don't like it, and I am ambivalent. To be discussed. Robert wants to rush off and implement it all before the language is designed. He understands that the ARG is still deciding at its usual slow pace. He also understands that implementation-defined aspects are allowed, so Pure can be an aspect without any blessing from ARG, and without using the "-gnatX" (extensions allowed) switch. **************************************************************** From: Robert Dewar Sent: Thursday, November 4, 2010 8:06 AM > Good. So all this discussion about with Pure is almost academic. I > will ignore it. John By no means academic, since I think it will become preferred usage for many Ada programmers. Certainly I will switch the GNAT run-time over to this style in time, since I prefer important semantic effects like this to be achieved with regular syntax rather than pragmas. Also aesthetically, I prefer package Types with Pure is type Int is new Integer; ... end Types; to package Types is pragma Pure; type Int is new Integer; ... end Types; since, never mind the pragma issue, the latter form makes the pragma look like one of the declarations inside the package, rather than setting an attribute of the package itself. BTW, this form is now fully implemented in GNAT **************************************************************** From: Bob Duff Sent: Thursday, November 4, 2010 8:25 AM > Certainly I will switch the GNAT run-time over to this style in time, > since I prefer important semantic effects like this to be achieved > with regular syntax rather than pragmas. Pragmas that place restrictions on what you can do (via compile-time or run-time checked -- doesn't matter) are OK by me. Pure is mostly (not entirely) in that category. Pragma Restrictions is the most obvious one. You could imagine "pragma Restrictions (No_Impure_Stuff);" which would mean roughly the same as "pragma Pure". **************************************************************** From: Robert Dewar Sent: Thursday, November 4, 2010 8:32 AM Right, I would prefer that all such pragmas (ones that serve simply to place restrictions on what can be done), be spelled Restriction or Profile, and that other pragmas that are in effect restrictions be avoided. And as you say, Pure goes a bit beyond this :-) I also prefer the clarity of the aspect pure being syntactically connected to the package, rather than appearing like the pragma to be merely one of the components of the package syntactically. **************************************************************** From: John Barnes Sent: Sunday, November 7, 2010 8:07 AM > Perhaps the whole business of allowing => True at all is wrong, just > insist on no parameter at all for these cases, after the whole > business of cancellation came up as a surprise when I first raised it > :-) Yes, that seems to be the nub of the issue. Cut out the => True. **************************************************************** From: Brad Moore Sent: Thursday, November 11, 2010 10:00 AM > I also prefer the clarity of the aspect pure being syntactically > connected to the package, rather than appearing like the pragma to be > merely one of the components of the package syntactically. I have the following library level generic instantiation. with Buffers.Simple_Unbounded; package String_Buffers.Simple_Unbounded_Buffer is new String_Buffers.Simple_Unbounded; pragma Preelaborate (String_Buffers.Simple_Unbounded_Buffer); pragma Remote_Types (String_Buffers.Simple_Unbounded_Buffer); Presumably, I'd now be able to write instead; with Buffers.Simple_Unbounded; package String_Buffers.Simple_Unbounded_Buffer with Remote_Types, Preelaborate is new String_Buffers.Simple_Unbounded; without having to respecify the package name on each of the aspects. That is quite a bit cleaner than the pragma version. **************************************************************** From: Robert Dewar Sent: Thursday, November 11, 2010 10:18 AM > without having to respecify the package name on each of the aspects. > That is quite a bit cleaner than the pragma version. I don't understand this, if this is indeed intended, it is a surprise to me. To me the aspect was just a syntactic equivalent for the pragma in a case like this. **************************************************************** From: Tucker Taft Sent: Thursday, November 11, 2010 11:03 AM > Presumably, I'd now be able to write instead; > > with Buffers.Simple_Unbounded; > > package String_Buffers.Simple_Unbounded_Buffer with Remote_Types, > Preelaborate is new String_Buffers.Simple_Unbounded; The syntax in 12.3 indicates that the aspect specification comes just before the ";" in an instantiation. Hence: package String_Buffers.Simple_Unbounded_Buffer is new String_Buffers.Simple_Unbounded with Remote_Types, Preelaborate; >> without having to respecify the package name on each of the aspects. >> That is quite a bit cleaner than the pragma version. > > I don't understand this, if this is indeed intended, it is a surprise > to me. To me the aspect was just a syntactic equivalent for the pragma > in a case like this. I don't understand what you don't understand ;-). Brad is pointing out an example of how the aspect specification can be cleaner (syntactically, I presume he means) than a categorization or elaboration-control pragma. Other than the positioning of the aspect clause, his example seems valid. **************************************************************** From: Robert Dewar Sent: Thursday, November 11, 2010 12:44 PM > I don't understand what you don't understand ;-). Brad is pointing > out an example of how the aspect specification can be cleaner > (syntactically, I presume he means) than a categorization or > elaboration-control pragma. Other than the positioning of the aspect > clause, his example seems valid. Ah because of the mispositioning, I missed them entirely glancing at his example, and thought he was somehow suggesting that they got inherited from the aspects of the template :-) > It is interesting to imagine extending the syntax to allow aspect > specifications on "with" clauses: > > with Ada.Text_IO > with Elaborate_All; > > Someone else might have already mentioned the issue with this > extension creating an error prone situation where leaving off a ";" > will produce a significantly different interpretation! > > Probably not worth going there... Don't like this idea at all. Bad enough to have WITH meaning two such very different things, and to put these conflicting uses into close alliance is a mistake (the phenomenon of the missing semicolon just reemphasizes the basic mistake The worse case is with Ada.Text_IO with My_Package; where now presumably you get a diagnostic saying My_Package is not a valid aspect name, instead of missing semicolon (and of course it's even worse if the name of the second package *does* happen to match an aspect name, as in with Ada.Text_IO with Size; | missing => or with Ada.Text_IO with Inline; | Inline aspect cannot be applied to package **************************************************************** From: John Barnes Sent: Thursday, November 11, 2010 5:42 PM from brief glimpses of this thread from a tropical rainforest in Queensland there seems to me to be a risk of with A_Mess; **************************************************************** From: Robert Dewar Sent: Thursday, November 11, 2010 7:07 PM Sorry I don't get your reaction at all, my query was answered completely, and I don't see any problem at all? **************************************************************** From: John Barnes Sent: Friday, November 12, 2010 5:21 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. And I continue to be cautious of providing multiple ways of doing one thing with concern for those who have to maintain software. If the standard libraries continue to have pragmas for pure, remote types etc, it could be a muddle for new user code to do those things a different way. Maybe we should move all the pragmas to J and rewrite the existing standard packages?? And it could add even more wretched pages to a certain book!! **************************************************************** From: Robert Dewar Sent: Friday, November 12, 2010 8:11 AM > Maybe we should move all the pragmas to J and rewrite the existing > standard packages?? I find this a waste of time. In fact the pragmas have uses not satisfied by the aspects and vice versa, I think it is fine to have both forms. And moving things to Annex J is always a waste of time, these things are not going away, and it would be unhelpful for pragma Restrictions (No_Obsolescent_Features) to ban all these pragmas, which are pervasive in the existing Ada code base. **************************************************************** From: Robert Dewar Sent: Friday, November 12, 2010 8:12 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. Please don't condition your response on a suggestion that there is no real enthusiasm for and which even the suggester disavows (allowing aspect on WITH clause). **************************************************************** 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: John Barnes Sent: Friday, November 12, 2010 5:21 AM ****************************************************************