CVS difference for ai05s/ai05-0229-1.txt
--- ai05s/ai05-0229-1.txt 2010/10/26 02:16:59 1.1
+++ ai05s/ai05-0229-1.txt 2010/11/13 03:23:06 1.2
@@ -13,9 +13,9 @@
!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.
+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
@@ -74,13 +74,14 @@
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:
+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.
+{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
@@ -92,7 +93,8 @@
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.
+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
@@ -156,7 +158,8 @@
> 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).
+> 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.
@@ -336,6 +339,1362 @@
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
****************************************************************
Questions? Ask the ACAA Technical Agent