Version 1.6 of ai05s/ai05-0229-1.txt

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: Bob Duff
Sent: Sunday, January 23, 2011  6:19 PM

The Fairfax minutes say:

    Bob will figure out the wording needed to allow Priority and CPU as
    aspects.

which I'm not sure how to approach.  Rewrite the pragma Priority section to
allow "task ... with Priority => ..."?  And say something in general about how
aspects can be misc pragmas not mentioned already in this AI?

Maybe the CPU thing should be ONLY an aspect (since everybody seems to prefer
aspects nowadays)?

I don't see anything about this in the Nov phone meeting minutes.

Anyway, I think somebody in the "Everything's an Aspect" school of thought ought
to take over the main authorship of this AI. The above "with a few topics" is
really referring to pretty-much everything.

****************************************************************

From: Randy Brukardt
Sent: Monday, January 24, 2011  10:14 PM

> Maybe the CPU thing should be ONLY an aspect (since everybody seems to
> prefer aspects nowadays)?

I don't think that there is anything general that needs to be said about
pragmas. Remember that there is supposed to be an entire annex listing
specifiable aspects. (That's the job I need to do, which is to discuss with you
the best form of that annex. I'll do that off-line here.)

As far as CPU goes, I thought we had decided to dump the pragma. But I obviously
didn't record that, so we'll probably have to talk about it again.

...
> Anyway, I think somebody in the "Everything's an Aspect"
> school of thought ought to take over the main authorship of this AI.
> The above "with a few topics" is really referring to pretty-much
> everything.

No, someone still has to write the text for the introduction to the aspect annex
and to suggest a common form for the entries in that annex. My job is just to
verify that it can be automated (we want it to work like the attribute annex in
terms of the actual source code). So that is more than just the stuff assigned
to Tucker.

The real problem is that I don't think we have anyone else that we can count on
to get the work done in a timely fashion. If you can find someone else to take
it over, I won't mind presuming that person isn't named Tucker. :-)

****************************************************************

From: Bob Duff
Sent: Tuesday, January 25, 2011  9:55 AM

> I don't think that there is anything general that needs to be said
> about pragmas.

I already wrote something general for representation pragmas.
People complained that it doesn't cover Inline and CPU.  (Others?)

>...Remember that there is supposed to be an entire annex listing
>specifiable aspects. (That's the job I need to do, which is to discuss
>with  you the best form of that annex. I'll do that off-line here.)
>
> As far as CPU goes, I thought we had decided to dump the pragma. But I
> obviously didn't record that, so we'll probably have to talk about it again.

If you mean CPU should be an aspect instead of a pragma, then I think that's a
good idea, and I do (vaguely) remember discussing that.  I think there are two
AI's that mention this pragma -- the one that defines it, and the one about
dispatching domains that I took over from Alan.

> ...
> > Anyway, I think somebody in the "Everything's an Aspect"
> > school of thought ought to take over the main authorship of this AI.
> > The above "with a few topics" is really referring to pretty-much
> > everything.
>
> No, someone still has to write the text for the introduction to the
> aspect annex and to suggest a common form for the entries in that
> annex. My job is just to verify that it can be automated (we want it
> to work like the attribute annex in terms of the actual source code).
> So that is more than just the stuff assigned to Tucker.

As I said privately, I'm not convinced such an Annex is necessary.

I already sent you an "introduction" privately.  No big deal.

As to the entries, I wouldn't do them like attributes (where the entire text is
duplicated in the annex).  I'd just put a command like:

    @aspect{CPU, "The CPU on which to execute a task."}

immediately before/after the place where CPU is defined.
This would generate no text inline, and generate alphabetized text in the Annex.

> The real problem is that I don't think we have anyone else that we can
> count on to get the work done in a timely fashion. If you can find
> someone else to take it over, I won't mind presuming that person isn't
> named Tucker. :-)

Shrug.  It seems simple enough to produce this annex.
I'm happy to write the words (if everybody (except me!) agrees that the RM
should weigh 50 pounds).

****************************************************************

From: Bob Duff
Sent: Tuesday, February  8, 2011  2:21 PM

Regarding AI05-0229-1, the minutes of the Jan 27, 2011 phone meeting say:

> Summary of action items:
> Bob:
...
>      AI05-0229-1 - Work out the form and contents of the aspect annex clause
>		     with Randy.
...

For "form", see below.

For "content", I don't see the hurry.  I think I should wait until we have a
more settled list of them, with relevant semantics.  I don't even know what they
all are, at this point.

As I said, I think it's easy: I plan to write an informal one-liner for each
aspect to go in this (useless!) annex.

> AI05-0229-1/01 Specifiable aspects

> Tucker suggests that we could put them as two separate sections in
> Annex K. That seems like a good idea as they are related. The title
> will be challenge, but we can leave that to Bob. [I'm expecting a
> title like "Useless listing of language-defined attributes and
> aspects". :-) - Editor.]

[The text here is part of version /02 of this AI. - Editor]

****************************************************************

From: Randy Brukardt
Sent: Saturday, February 12, 2011  12:27 AM

...
> For "content", I don't see the hurry.  I think I should wait until we
> have a more settled list of them, with relevant semantics.  I don't
> even know what they all are, at this point.

I had wanted some examples for Draft 11. But since I didn't add this annex in
that draft, you'll have until mid-March to provide the content.

Keep in mind that we're supposed to finish all work on the standard at this
upcoming meeting, and the next AARM draft will be going out for editorial and
National Body review. The annex will need to be in that version.

I don't plan to put the actual entries into the AI, just the standard.

...
> Precondition: Specifies a condition that must hold true in order to
> call a given subprogram.

The existing annexes include an (automated) cross-reference to the section of
definition. We'll certainly do that here, too; that's kinda the point. So this
will end with "See 13.3.1.". You'll need to keep that in mind as you write
these.

> Size: See attribute below.

That wouldn't make any sense, with the automatic cross-reference.

Size: See attribute below. See 13.3.

!!!

>     Or maybe:
>
> Size: Size in bits of a subtype or object (see Size attribute below).

Same here:

Size: Size in bits of a subtype or object (see Size attribute below). See 13.3.

The following would work, of course.

Size: Size in bits of a subtype or object. See 13.3.

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 10, 2011  2:43 AM

...
> And I finished the rest of my ARG homework, too, I think.

Back on January 24th, you wrote:

I have completed all of the above homework (yay!), except for AI05-0229-1.
The Fairfax minutes say:

    Bob will figure out the wording needed to allow Priority and CPU as
    aspects.

which I'm not sure how to approach.  Rewrite the pragma Priority section to
allow "task ... with Priority => ..."?  And say something in general about how
aspects can be misc pragmas not mentioned already in this AI?

Maybe the CPU thing should be ONLY an aspect (since everybody seems to prefer
aspects nowadays

====

You never did this. I'm happy to tell you how to approach it - just write the
wording needed to augment/replace that for each pragma. I don't think there is
any way to generalize it, and I don't see much point anyway.

You'll also have to help me figure out what parts of your mail from last October
belongs in this AI; I never considered it as approproate AI contents but since I
don't seem to be getting anything else I guess I'll have to try to figure out
how to turn it into something that makes sense as wording and AARM notes...

****************************************************************

From: Bob Duff
Sent: Friday, February 11, 2011  9:05 AM

> Maybe the CPU thing should be ONLY an aspect (since everybody seems to
> prefer aspects nowadays

Nobody answered this question.  Should I submit a new version of AI05-0171-1,
"Pragma CPU and Ravenscar Profile" with a different subject, and change the
pragma into an aspect?  That AI is currently ARG Approved.

AI05-0167-1, "Managing affinities for programs executing on multiprocessors"
refers to pragma CPU, so should I submit a new version of that AI, too?

And if CPU is an aspect instead of a pragma, then should I change
Dispatching_Domain (in AI05-0167-1) to also be an aspect?

Are the latest versions of these AIs in the CVS repository?

...
> You'll also have to help me figure out what parts of your mail from
> last October belongs in this AI; I never considered it as approproate
> AI contents but since I don't seem to be getting anything else I guess
> I'll have to try to figure out how to turn it into something that
> makes sense as wording and AARM notes...

Yes, please.  I'm not the one pushing for everything under the sun to be turned
into an aspect.  I don't think it's feasible, so those who do should put up some
wording.  I did my best, but don't be surprised that what I did is incomplete.

****************************************************************

From: Randy Brukardt
Sent: Friday, February 11, 2011  12:57 PM

> Nobody answered this question.  Should I submit a new version of
> AI05-0171-1, "Pragma CPU and Ravenscar Profile" with a different
> subject, and change the pragma into an aspect?
> That AI is currently ARG Approved.

That's fine, or you can just put new wording into AI05-0229-1. AIs can still be
changed until they are WG 9 approved, so it is probably better that we go that
way.

> AI05-0167-1, "Managing affinities for programs executing on
> multiprocessors" refers to pragma CPU, so should I submit a new
> version of that AI, too?

Sure.

> And if CPU is an aspect instead of a pragma, then should I change
> Dispatching_Domain (in AI05-0167-1) to also be an aspect?

I think so.

> Are the latest versions of these AIs in the CVS repository?

Yes, with the possible exception of the AI-167 you sent the other day. I've
filed it here, but I don't know if I've uploaded the changes since I did that.

...
> > You'll also have to help me figure out what parts of your mail from
> > last October belongs in this AI; I never considered it as
> > approproate AI contents but since I don't seem to be getting
> > anything else I guess I'll have to try to figure out how to turn it
> > into something that makes sense as wording and AARM notes...
>
> Yes, please.  I'm not the one pushing for everything under the sun to
> be turned into an aspect.  I don't think it's feasible, so those who
> do should put up some wording.  I did my best, but don't be surprised
> that what I did is incomplete.

OK. We can do that off-line (no need to clutter this list with discussions of AI
formats).

****************************************************************

From: Alan Burns
Sent: Saturday, February 12, 2011  6:01 AM

I've not been following the discussions about aspects, so I'm not sure what the
consequences are for changing from a pragma to an aspect - but for us real-time
folk a consistent language style is what we most need. We already have pragmas
for priority, profiles and initial deadline, so can we not also have pragmas for
affinities?

Or are all these other pragmas also changing?

In telling people about the support that Ada provides for multicores I would
prefer not to have to also talk about changes to the things they already know
(unless the change to aspect in just a pure syntax change).

****************************************************************

From: Randy Brukardt
Sent: Saturday, February 12, 2011  8:22 PM

> I've not been following the discussions about aspects, so I'm not sure
> what the consequences are for changing from a pragma to an aspect -
> but for us real-time folk a consistent language style is what we most
> need.
> We already have pragmas for priority, profiles and initial deadline,
> so can we not also have pragmas for affinities?
>
> Or are all these other pragmas also changing?

Virtually all pragmas will be also available in aspect form. In new code,
aspects will be preferred (at least IMHO).

> In telling people about the support that Ada provides for multicores I
> would prefer not to have to also talk about changes to the things they
> already know (unless the change to aspect in just a pure syntax
> change).

There is no semantic difference between specifying properties with attributes,
pragmas, or aspects. So it is just a syntax change.

****************************************************************

From: Alan Burns
Sent: Monday, February 14, 2011  7:54 AM

> Virtually all pragmas will be also available in aspect form. In new
> code, aspects will be preferred (at least IMHO).

Can I put in a plea for both forms being available with multiprocessor pragmas
(ie not just aspects)

****************************************************************

From: Bob Duff
Sent: Saturday, February 12, 2011  7:29 AM

> ...
> > For "content", I don't see the hurry.  I think I should wait until
> > we have a more settled list of them, with relevant semantics.  I
> > don't even know what they all are, at this point.
>
> I had wanted some examples for Draft 11. But since I didn't add this
> annex in that draft, you'll have until mid-March to provide the content.

Well, I've given several off-the-cuff examples in the past.

How about you give me a macro format, and a list of aspects, and I'll write them
all up?  If your list is incomplete, I'll complete it later.  I'll give you
something like:

    After 1.2.3(45):
    @aspect-index-entry{Precondition|Specifies a condition that must
    hold true in order to call a given subprogram.}

(or whatever the correct macro-call syntax is -- I assume it's still vaguely based on Scribe).  The macro will automatically generate an entry in the Annex, including the section number, plus an entry in the index.

Tell me whether you want the macro call before, after, or part of the relevant
paragraph.

> Keep in mind that we're supposed to finish all work on the standard at
> this upcoming meeting, and the next AARM draft will be going out for
> editorial and National Body review. The annex will need to be in that version.
>
> I don't plan to put the actual entries into the AI, just the standard.
>
> ...
> > Precondition: Specifies a condition that must hold true in order to
> > call a given subprogram.
>
> The existing annexes include an (automated) cross-reference to the
> section of definition. We'll certainly do that here, too; that's kinda
> the point. So this will end with "See 13.3.1.". You'll need to keep
> that in mind as you write these.
>
> > Size: See attribute below.
>
> That wouldn't make any sense, with the automatic cross-reference.
>
> Size: See attribute below. See 13.3.
>
> !!!

OK, then:

Size (also attribute). See 13.3.

And the intro would say "Some aspects are also attributes, as noted, see
Whatever.

> >     Or maybe:
> >
> > Size: Size in bits of a subtype or object (see Size attribute below).
>
> Same here:
>
> Size: Size in bits of a subtype or object (see Size attribute below).
> See 13.3.

If you insist on defining every attribute THREE times, then:

Size: Size in bits of a subtype or object (same as Size attribute).
See 13.3.

> The following would work, of course.
>
> Size: Size in bits of a subtype or object. See 13.3.

Don't you think it's useful to say which aspects are also attributes or pragmas?
(Preferably instead of describing them, but in addition, if you insist.)

In that case, how about 3 macros, one for aspects that are also pragams, one for
also-attrs, and one for the rest? They can generate appropriate canned text,
such as " (also an attribute)".

Actually, forget the pragma one -- we want people to switch entirely over to the
aspect.  But attributes are still useful as queries.

Here's another idea (sorry for the stream-of-conciousness e-mail!):

Size: X'Size is the size in bits of subtype or object X.
See 13.3.

****************************************************************

From: Randy Brukardt
Sent: Saturday, February 12, 2011  8:10 AM

> How about you give me a macro format, and a list of aspects, and I'll
> write them all up?  If your list is incomplete, I'll complete it
> later.  I'll give you something like:
>
>     After 1.2.3(45):
>     @aspect-index-entry{Precondition|Specifies a condition that must
>     hold true in order to call a given subprogram.}
>
> (or whatever the correct macro-call syntax is -- I assume it's still
> vaguely based on Scribe).  The macro will automatically generate an
> entry in the Annex, including the section number, plus an entry in the
> index.

That's fine, although just pairs (aspect, description) would be enough.

Looking at the existing commands, I think we'll have something like

@chgaspectdesc{Version=[<version>],Kind=[<kind>],Aspect=[<text>],Text=[<text
>]}

(So we have everything we'll need going forward.) For this version, that will
look like:

@chgaspectdesc{Version=[3],Kind=[AddedNormal],Aspect=[Precondition],
Text=[Specifies a condition that must hold true in order to call a given subprogram.]}

The first two items will be the same for all of these.

> Tell me whether you want the macro call before, after, or part of the
> relevant paragraph.

I think after (like @ImplDef and @ChgImplDef).

...
> If you insist on defining every attribute THREE times, then:
>
> Size: Size in bits of a subtype or object (same as Size attribute).
> See 13.3.

This isn't a definition, it's a reference list.

> > The following would work, of course.
> >
> > Size: Size in bits of a subtype or object. See 13.3.
>
> Don't you think it's useful to say which aspects are also attributes
> or pragmas?  (Preferably instead of describing them, but in addition,
> if you insist.)

I don't see the point off-hand, but I could be convinced.

The typical use for this annex is when you are looking for an aspect that you
want to specify whose name you don't remember. Whether or not it can be queried
with an attribute isn't terribly relevant to that. If you know the name, you'd
probably use the main index or the search page. It's only when you don't know
the name that these lists come in handy.

One can imagine that the list of aspects is of things that you can specify; the
list of attributes is of things you can query. These seem like disjoint lists to
me.

> In that case, how about 3 macros, one for aspects that are also
> pragams, one for also-attrs, and one for the rest?
> They can generate appropriate canned text, such as " (also an
> attribute)".

Sounds like overkill to me.

> Actually, forget the pragma one -- we want people to switch entirely
> over to the aspect.  But attributes are still useful as queries.
>
> Here's another idea (sorry for the stream-of-conciousness e-mail!):
>
> Size: X'Size is the size in bits of subtype or object X.
> See 13.3.

I suppose that would work. Still doesn't seem necessary to me. Does anyone else
have an opinion about whether these entries should include information about the
associated pragma or attribute?

****************************************************************