Version 1.1 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).

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