Version 1.13 of ai05s/ai05-0215-1.txt

Unformatted version of ai05s/ai05-0215-1.txt version 1.13
Other versions for file ai05s/ai05-0215-1.txt

!standard 9.5(9)          11-05-11 AI05-0215-1/09
!standard 9.5.4(3)
!standard 9.5.4(5)
!standard E.2.2(14)
!class Amendment 11-04-28
!status Amendment 2012 11-05-11
!status ARG Approved (by Letter Ballot) 9-1-1 11-05-16
!status work item 10-04-30
!status ARG Approved 6-0-2 11-04-07
!status work item 10-06-12
!status received 10-03-26
!priority Low
!difficulty Easy
!qualifier Omission
!subject Pragma Implemented should be an aspect, renamed, and better defined
!summary
The aspect Synchronization is introduced as the proper way of specifying how a synchronized interface operation must be implemented (replacing the pragma Implemented of AI05-0030-2).
!question
(1) I don't see any rule that says that you can't write two
Implemented pragmas for the same subprogram. (If the Standard said that Implemented were a representation pragma, as it does for No_Return, this would follow automatically; but it doesn't say that anywhere.)
(2) The pragma doesn't make sense unless Implemented pragmas
explicitly specified for subprograms apply to inherited subprograms. But there is no wording to that effect in the Standard. 3.9.2(10) says explicitly that the convention was inherited for some inherited subprograms, so similar wording is needed for Implemented (and No_Return as well).
(3) 9.5.4(3/3) says:
"The procedure_or_entry_name of a requeue_statement shall resolve to denote a procedure or an entry (the requeue target) that either has no parameters, or that has a profile that is type conformant (see 6.3.1) with the profile of the innermost enclosing entry_body or accept_statement."
But this makes no sense for a procedure; the procedure has to have a first parameter that is of a synchronized type. So there can't be a procedure with no parameters here. Moreover, because of this first parameter, the profile can't conform with the enclosing entry. Probably it is the prefixed view profile that has to conform.
Similar problems arise in 9.5.4(5/3).
(4) We're changing many pragmas to be primarily aspects; it seems that
pragma Implemented should be an aspect as well.
!recommendation
(See Summary.)
!wording
Delete 9.5 (10/3-11/3).
Modify 9.5 (12/3) as follows:
Synchronization_Kind ::= By_Entry | By_Protected_Procedure | Optional
Modify 9.5(13/3 - 16/3) as follows:
For the declaration of a primitive procedure of a synchronized tagged type the following language-defined representation aspect may be specified with an aspect_specification (see 13.3.1):
Synchronization.
If specified, the aspect definition shall be a Synchronization_Kind.
The Synchronization_Kind By_Protected_Procedure shall not be applied to a primitive procedure of a task interface.
A procedure for which the specified Synchronization_Kind is By_Entry shall be implemented by an entry. A procedure for which the specified Synchronization_Kind is By_Protected_Procedure shall be implemented by a protected procedure. A procedure for which the specified Synchronization_Kind is Optional may be implemented by an entry or by a procedure (including a protected procedure).
If a primitive procedure overrides an inherited operation for which the Synchronization aspect has been specified to be By_Entry or By_Protected_Procedure, then any specification of the aspect Synchronization applied to the overriding operation shall have the same Synchronization_Kind.
Modify 9.5(18/3) as follows:
[A pragma Implemented is said to apply to the procedure denoted by its procedure_local_name.] {Inherited subprograms inherit the Synchronization aspect, if any, from the corresponding subprogram of the parent or progenitor type.} If an overriding operation does not have a [pragma] {directly specified} Synchronization {aspect} then [any pragma Implemented applying to] {the Synchronization aspect of} the inherited operation [applies to] {is inherited by} the overriding operation.
Modify 9.5.4(3/3) as follows:
The procedure_or_entry_name of a requeue_statement shall resolve to denote a procedure or an entry (the requeue target){. The profile of the entry, or the profile or prefixed profile of the procedure, shall} [that] either [has] {have} no parameters, or [that has a profile that is] {be} type conformant (see 6.3.1) with the profile of the innermost enclosing entry_body or accept_statement.
Modify 9.5.4(5/3) as follows:
If the requeue target has parameters, then its {(prefixed)} profile shall be subtype conformant with the profile of the innermost enclosing callable construct.
Modify 9.5.4(5.1/3) as follows:
If the target is a procedure, the name shall denote a renaming of an entry, or shall denote {a view or} a prefixed view of a primitive subprogram of a synchronized interface, where the first parameter of the unprefixed view of the primitive subprogram shall be a controlling parameter, and [an Implemented pragma] {the Synchronization aspect shall be specified} with [implementation_kind]{Synchronization_Kind} By_Entry [shall apply to] {for} the primitive subprogram.
Modify E.2.2(14.1/3) [from AI05-0060-1]:
* The corresponding specific type shall not have a primitive procedure {with the Synchronization aspect specified}[to which a pragma Implemented applies] unless the [implementation_kind]{synchronization_kind} [of the pragma] is {Optional}[By_Any];
!discussion
!corrigendum 9.5(9)
Insert after the paragraph:
Any call on a protected procedure or entry of a target protected object is defined to be an update to the object, as is a requeue on such an entry.
the new paragraphs:
Syntax
synchronization_kind ::= By_Entry | By_Protected_Procedure | Optional
Static Semantics
For the declaration of a primitive procedure of a synchronized tagged type the following language-defined representation aspect may be specified with an aspect_specification (see 13.3.1):
Synchronization
If specified, the aspect definition shall be a synchronization_kind.
Inherited subprograms inherit the Synchronization aspect, if any, from the corresponding subprogram of the parent or progenitor type. If an overriding operation does not have a directly specified Synchronization aspect then the Synchronization aspect of the inherited operation is inherited by the overriding operation.
Legality Rules
The synchronization_kind By_Protected_Procedure shall not be applied to a primitive procedure of a task interface.
A procedure for which the specified synchronization_kind is By_Entry shall be implemented by an entry. A procedure for which the specified synchronization_kind is By_Protected_Procedure shall be implemented by a protected procedure. A procedure for which the specified synchronization_kind is Optional may be implemented by an entry or by a procedure (including a protected procedure).
If a primitive procedure overrides an inherited operation for which the Synchronization aspect has been specified to be By_Entry or By_Protected_Procedure, then any specification of the aspect Synchronization applied to the overriding operation shall have the same synchronization_kind.
In addition to the places where Legality Rules normally apply (see 12.3), these rules apply also in the private part of an instance of a generic unit.
NOTE 18 The synchronization_kind By_Protected_Procedure implies that the operation will not block.
!corrigendum 9.5.4(3)
Replace the paragraph:
The entry_name of a requeue_statement shall resolve to denote an entry (the target entry) that either has no parameters, or that has a profile that is type conformant (see 6.3.1) with the profile of the innermost enclosing entry_body or accept_statement.
by:
The procedure_or_entry_name of a requeue_statement shall resolve to denote a procedure or an entry (the requeue target). The profile of the entry, or the profile or prefixed profile of the procedure, shall either have no parameters, or be type conformant (see 6.3.1) with the profile of the innermost enclosing entry_body or accept_statement.
!corrigendum 9.5.4(5)
Replace the paragraph:
If the target entry has parameters, then its profile shall be subtype conformant with the profile of the innermost enclosing callable construct.
by:
If the requeue target has parameters, then its (prefixed) profile shall be subtype conformant with the profile of the innermost enclosing callable construct.
If the target is a procedure, the name shall denote a renaming of an entry, or shall denote a view or a prefixed view of a primitive subprogram of a synchronized interface, where the first parameter of the unprefixed view of the primitive subprogram shall be a controlling parameter, and the Synchronization aspect shall be specified with synchronization_kind By_Entry for the primitive subprogram.
!corrigendum E.2.2(14/2)
Insert after the paragraph:
the new paragraph:
!ACATS Test
ACATS tests are needed as explained in AI05-0030-2.
!appendix

!topic Missing rules in Implemented definition?
!reference 9.5(10-18)
!from Adam Beneschan 10-03-26
!discussion


(1) I don't see any rule that says that you can't write two
    Implemented pragmas for the same subprogram.  (If the RM said that
    Implemented were a representation pragma, as it does for
    No_Return, I think this would follow automatically; but I don't
    think it says that anywhere.)

(2) The pragma doesn't make sense unless Implemented pragmas
    explicitly specified for subprograms apply to inherited
    subprograms.  However, I haven't found anywhere in the RM that
    says that pragmas that apply to subprograms automatically apply to
    inherited subprograms.  Nothing in 3.4 (which is the main place
    subprogram inheritance is discussed) says anything about
    subprograms inheriting anything other than the name and profile.
    In 3.9.2(10), it appears that it was deemed necessary to say
    explicitly that the convention was inherited for some inherited
    subprograms.  So I think that somewhere, either 9.5 should say
    that if Implemented applies to a subprogram it applies to an
    inherited subprogram (and 6.5.1 needs to say something similar
    about No_Return), or there needs to be a more general statement
    about what properties or characteristics are inherited by an
    inherited subprogram.

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

!topic Errors in AI05-0030-2
!reference 9.5.4
!from Adam Beneschan 10-03-30
!discussion

There appear to be some errors in the changes made for AI05-0030-2.

9.5.4(3/3): "The procedure_or_entry_name of a requeue_statement shall resolve
to denote a procedure or an entry (the requeue target) that either has no
parameters, or that has a profile that is type conformant (see 6.3.1) with
the profile of the innermost enclosing entry_body or accept_statement."

First of all, I note that in the online version
(www.adaic.org/standards/1zaarm/html/AA-9-5-4.html), the paragraph didn't
get updated correctly; it says "denote an entry" rather than "denote a
procedure or entry" which of course defeats the whole purpose.  But this
error isn't worth changing since the whole paragraph is wrong anyway.  If
the procedure_or_entry_name denotes a procedure, doesn't it have to denote
a procedure whose first parameter is a synchronized interface type (or access-to-)?
If that's the case, than it certainly can't resolve to a procedure with
no parameters.
Also, if it's a procedure, its profile can't be type conformant with that
of the enclosing entry; rather, isn't it the procedure's *prefixed view
profile* that has to be type conformant?  So I think this just needs to
be redone.  I'm not sure exactly how, since I don't know what you want to
put in a Name Resolution Rule.

9.5.4(5/3) has the same problem: "If the requeue target has parameters, then
its profile shall be subtype conformant with the profile of then innermost
enclosing callable construct"---again, if the requeue target is a procedure,
the prefixed view profile is what has to be subtype conformant.  Also, if
the requeue target is a procedure with *one* parameter, then this rule
wouldn't apply---the one parameter is the controlling synchronized interface
parameter, but otherwise it should be treated like a parameterless entry.
So maybe this needs to be something like

    If the requeue target is an entry that has parameters, then its
    profile shall be subtype conformant with the profile of the
    innermost enclosing callable construct.  If the requeue target is
    a prefixed view of primitive subprogram [procedure] of a
    synchronized interface, and if the subprogram has more than one
    parameter, then its prefixed view profile shall be subtype
    conformant with the profile of the innermost enclosing callable
    construct.

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

From: Bob Duff
Sent: Sunday, January 23, 2011  2:35 PM

...
>     * AI05-0215-1 Suggest a better aspect name than "Implemented" [Nov.
> phone meeting]

I don't see anything about this in those minutes.
But anyway, here's my suggested name changes (for the pragma and it allowed
arguments):

    Implemented --> Synchronized_Implementation
    By_Entry --> Entry
    By_Protected_Procedure --> Protected_Procedure
    By_Any --> Any

Or maybe just change the pragma name.

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

From: John Barnes
Sent: Sunday, January 23, 2011  4:15 PM

Seems preferable as it is to me.

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

From: Robert Dewar
Sent: Sunday, January 23, 2011  5:37 PM

>      Implemented -->  Synchronized_Implementation

I find this much too long

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

From: Bob Duff
Sent: Sunday, January 23, 2011  5:46 PM

Do you have a better idea?

Does anybody remember why we wanted to change this name?
I think it's because (1) "Implemented" is way to general a term for what this
thing does, and (2) it doesn't read well as an aspect.  But I don't really
remember the discussion. And I'm still ambivalent about shoe-horning everything
under the Sun into "aspect" syntax.  The minutes don't clue me in.

Anyway, I don't buy "too long", because it's rarely used.
It will increase the total size of all Ada programs world wide by perhaps
0.000_001%".  ;-)

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

From: Robert Dewar
Sent: Sunday, January 23, 2011  5:52 PM

> Does anybody remember why we wanted to change this name?
> I think it's because (1) "Implemented" is way to general a term for
> what this thing does, and (2) it doesn't read well as an aspect.  But
> I don't really remember the discussion.
> And I'm still ambivalent about shoe-horning everything under the Sun
> into "aspect" syntax.  The minutes don't clue me in.

I think the current proposal is better than your proposed substitute.

> Anyway, I don't buy "too long", because it's rarely used.
> It will increase the total size of all Ada programs world wide by
> perhaps 0.000_001%".  ;-)

The fact that a nasty long name is not going to be used often is not a good
enough justification for me.

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

From: Randy Brukardt
Sent: Monday, January 24, 2011  9:36 PM

...
> Does anybody remember why we wanted to change this name?

My recollection is that you were the one that wanted to change it, so I would
have hoped you remembered why. ;-)

> I think it's because (1) "Implemented" is way to general a term for
> what this thing does, and (2) it doesn't read well as an aspect.  But
> I don't really remember the discussion.
> And I'm still ambivalent about shoe-horning everything under the Sun
> into "aspect" syntax.  The minutes don't clue me in.

I think that sounds about right. "Implemented" doesn't seem to indicate at all
what it is about. It's really "the overriding or implemented-by routine must be
of this kind". "Implemented by" only is true for task and protected operations,
and this definition is wider than that anyway.

I think we were hoping that you would have a wonderful idea that's nice and
short and descriptive. Part of the problem is that *Ada* doesn't have such a
term, so it's asking a lot for something meaningful.

Perhaps someone will have a better idea from these musings.

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

From: Brad Moore
Sent: Tuesday, January 25, 2011  8:33 AM

> Perhaps someone will have a better idea from these musings.

How about just Synchronized?  The word Implemented doesn't really add anything.
Also, this allows us to get rid of  By_Any. If the pragma doesn't have an argument, that would be the By_Any case.

     Implemented -->  Synchronized
     By_Entry -->  Entry
     By_Protected_Procedure -->  Protected_Procedure
     By_Any -->

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

From: Bob Duff
Sent: Tuesday, January 25, 2011  8:45 AM

> How about just Synchronized?  The word Implemented doesn't really add
> anything.

I like it.

> Also, this allows us to get rid of  By_Any. If the pragma doesn't have
> an argument, that would be the By_Any case.

I'm not sure about that.  It's not intuitively obvious that "pragma
Synchronized;" means "by-any".

>      Implemented -->  Synchronized
>      By_Entry -->  Entry
>      By_Protected_Procedure -->  Protected_Procedure

Agreed.

>      By_Any -->

I think I prefer "By_Any --> Any".

OTOH, I'd be happy to keep the "By_" prefixes, if folks like them.  The main
thing is to rename the pragma/aspect itself.

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

From: Tucker Taft
Sent: Tuesday, January 25, 2011  8:49 AM

Unfortunately, both "synchronized" and "entry" are reserved words.

Perhaps:

Is_Synchronized => By_Entry
Is_Synchronized => By_Protected_Procedure
Is_Synchronized [=> True]
Is_Synchronized => False

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

From: Bob Duff
Sent: Tuesday, January 25, 2011  8:59 AM

> Unfortunately, both "synchronized" and "entry" are reserved words.

I was thinking that's OK for pragmas.  But now I realize that if you want to
make it an aspect, reserved words are a no-no.

> Perhaps:
>
> Is_Synchronized => By_Entry
> Is_Synchronized => By_Protected_Procedure Is_Synchronized [=> True]
> Is_Synchronized => False

Looks good.

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

From: Brad Moore
Sent: Tuesday, January 25, 2011  9:42 AM

I suppose "synchronous" could be another alternative, that isn't a reserved
word. If that were the case, is it just the aspect name that causes a problem?
Or would the aspect qualifiers also present a problem if they conflict
with reserved words.

ie
   pragma Synchronous (Entry);
   pragma Synchronous (Protected_Procedure);

     Synchronous => Entry
     Synchronous => Protected_Procedure
     Synchronous [=> True]
     Syncrhonous => False;

In any case, I'm not sure which I like better. They both look good to
me, and an improvement over the pragma Implemented.

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

From: John Barnes
Sent: Tuesday, January 25, 2011  11:23 AM

I am happy with Is_Synchronized and keeping By. I much prefer By_Any to True or
False.  Having them all start By_ has a nice rhythm to it.

By_Whatever, By_Any_Old_How, By_George...

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

From: John Barnes
Sent: Tuesday, January 25, 2011  2:02 PM

I should have added By_Hook_Or_By_Crook.

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

From: Edmond Schonberg
Sent: Tuesday, January 25, 2011  3:36 PM

Not to mention By_Mistake and By_Pure_Luck.

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

From: Edmond Schonberg
Sent: Tuesday, March 15, 2011  2:31 PM

> AI05-0215-1: (see minutes of meeting #42)

There is no mention of 0215 in the October minutes. Bob had the same reaction in
January, and then went on to propose different values for the corresponding
aspect. Given that this is a correction of another AI, should we just withdraw
AI05-030 (even though WG9 approved)  and rewrite it without the Implemented
pragma (no one uses it yet) and with the new Aspect Implemented_By?

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

From: Randy Brukardt
Sent: Tuesday, March 15, 2011  2:50 PM

> There is no mention of 0215 in the October minutes.

Sorry, it was the November phone meeting. But that doesn't say much:

Ed will take this one, and convert it to an aspect, removing the pragma.
[Editor's note: change the subject when this is done, and add a question to this
effect.] Is the name "Implemented" good? We don't have a better idea, and
typical formatting puts the aspect by itself on the left. Bob thinks the name is
too general; he will take this off-line and try to come with a better name.
"Implemented_By_Entry" as a boolean aspect is a thought. "Implemented_By_Entry
=> False" is really "maybe", not "no", so that isn't perfect. We'll let Bob
think about this.

[End of November minutes.]

> Bob had
> the same reaction in January, and then went on to propose different
> values for the corresponding aspect.

That was Bob responding to the action item above.

> Given that
> this is a correction of another AI, should we just withdraw AI05-030
> (even though WG9 approved)  and rewrite it without the Implemented
> pragma (no one uses it yet) and with the new Aspect Implemented_By?

I don't think we want to withdraw it completely, since quite a bit of it will be
unchanged. (Certainly all of the stuff about Requeue has no reason to change.)

So I think you should just write up this AI saying that it is replacing
paragraphs whatever to whenever. But we're not going to "withdraw" a WG 9
approved AI (even if this one ends up rewriting 90% of the paragraphs -- which I
doubt).

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

From: Bob Duff
Sent: Tuesday, March 15, 2011  3:51 PM

> > Bob had
> > the same reaction in January, and then went on to propose different
> > values for the corresponding aspect.
>
> That was Bob responding to the action item above.

I still pretty-much hate the name Implemented (or Implemented_By), for the
reasons I already mentioned.

Tucker's suggestion ("Tuesday, January 25, 2011  8:49 AM", in the !appendix)
seems perfect to me:

Is_Synchronized => By_Entry
Is_Synchronized => By_Protected_Procedure
Is_Synchronized [=> True]
Is_Synchronized => False

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

From: Edmond Schonberg
Sent: Tuesday, March 15, 2011  4:20 PM

I agree with this choice, that should be the name and the legal values of the
new aspect.

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

From: Randy Brukardt
Sent: Tuesday, March 15, 2011  4:31 PM

Fine by me, and since you are writing it up, you get to make the recommended
choice anyway. If someone wants a choice other than the one you make, *they* can
write it up. That should minimize the alternatives proposed. ;-)

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

From: Bob Duff
Sent: Tuesday, March 15, 2011  4:41 PM

> > Is_Synchronized => By_Entry
> > Is_Synchronized => By_Protected_Procedure Is_Synchronized [=> True]
> > Is_Synchronized => False
>
> I agree with this choice, that should be the name and the legal values
> of the new aspect.

Note that True and False here, are not values of type Boolean.
They are "identifiers specific to an aspect".  That's not a problem, just a
language-lawyerly oddity.

It means you can't say:

    Is_Synchronized => Boolean'(False)
    Is_Synchronized => Standard.False

    X : constant Boolean := False;
    ...
    Is_Synchronized => X

If you don't like that, I suppose you could define an enumeration type
(By_Entry, By_Protected_Procedure, True, False), or perhaps (By_Entry,
By_Protected_Procedure, Yes, No). But I wouldn't bother with that.

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

From: Edmond Schonberg
Sent: Wednesday, March 16, 2011  3:55 PM

Here is an aspect-centric version of this AI.  The new aspect is
Is_Synchronized, and the aspect definition is a synchronization_kind:

      Synchronization_Kind ::= By_Entry | By_Protected_Procedure | By_Any.

I did not see the need to have an additional value to specify a default, given
the stated inheritance rules. I guess Bob will move the skeleton of the previous
version of the AI to annex J.

[This is version /02 of the AI - Editor.]

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

From: Tucker Taft
Sent: Wednesday, March 16, 2011  4:06 PM

Can't say I love "Is_Synchronized => By_Any"
Doesn't make a whole lot of sense to me.
"Yes" or "True" would read better, IMHO.

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

From: Edmond Schonberg
Sent: Wednesday, March 16, 2011  4:14 PM

"True" seems confusing because this is not a boolean aspect. I guess
Is_Synchronized => Yes is acceptable, to indicate that some subsequent
overriding operation will be a legal target of a requeue operation.

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

From: Bob Duff
Sent: Wednesday, March 16, 2011  5:01 PM

> I did not see the need to have an additional value to specify a
> default, = given the stated inheritance rules.

OK.

> I guess Bob will move the skeleton of the previous version of the AI
> to = annex J.

I think that's Randy's job.

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

From: Randy Brukardt
Sent: Wednesday, March 16, 2011  9:46 PM

> I guess Bob will move the skeleton of the previous version of the AI
> to annex J.

I thought that we were not even going to define a pragma for this one (unlike
CPU). Pragmas are nasty for subprograms, and these are subprograms. So no need
to put anything in Annex J.

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

From: Randy Brukardt
Sent: Wednesday, March 16, 2011  9:53 PM

> Can't say I love "Is_Synchronized => By_Any"
> Doesn't make a whole lot of sense to me.
> "Yes" or "True" would read better, IMHO.

Except that it really means that it is not necessarily synchronized (it can be a
normal subprogram, which is not synchronized by any imagination), so it is more
like "Maybe_Not".

     Is_Synchronized => Maybe_Not

Perfect. ;-)

     Is_Synchronized => Probably_Not

     Is_Synchronized => Hardly_Ever

     Is_Synchronized => Not_Specified

(but specifying something to be Not_Specified seems like a tautology :-)

     Is_Synchronized => Not_Required

     Is_Synchronized => Not_Necessarily_Synchronized

Fill in your own ideas here.

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

From: Randy Brukardt
Sent: Wednesday, March 16, 2011  10:14 PM

> Here is an aspect-centric version of this AI.

Your version seem to have lost the revised 9.5(18/3) that defined the
inheritance of the aspects. (This was part of the fixes of this AI, not
something that previously existed - there are no rules in the Standard that
described inheritance for aspects of subprograms - of course, Tucker might be
writing those as I write this.) Anyway, I put it back, pending whatever Tucker
does in 13.1.

Modify 9.5(18/3):

  [A pragma Implemented is said to *apply* to the procedure denoted
  by its *procedure_*local_name.] {Inherited subprograms inherit the
  Implemented aspect, if any, from the corresponding subprogram of the
  parent or progenitor type.}  If an overriding operation does not have
  a [pragma] {directly specified} Implemented {aspect} then [any pragma
  Implemented applying to] {Implemented aspect of} the inherited
  operation [applies to] {is inherited by} the overriding operation.

The last paragraph doesn't mark the changes properly (since
"implementation-kind" and "Implemented" were changed without markings):

Modify 9.5.4(5.1/3):

  If the target is a procedure, the name shall denote a rename of an
  entry, or shall denote {a view or} a prefixed view of a primitive
  subprogram of a synchronized interface, where the first parameter of
  the unprefixed view of the primitive subprogram shall be a controlling
  parameter, and [an Implemented pragma] {the Is_Synchronized aspect shall be
  specified} with [implementation_kind]{Synchronization_Kind} By_Entry [shall
  apply to] {for} the primitive subprogram.

I've corrected the AI with these changes.

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

From: Edmond Schonberg
Sent: Wednesday, March 16, 2011  10:20 PM

> Your version seem to have lost the revised 9.5(18/3) that defined the
> inheritance of the aspects. (This was part of the fixes of this AI,
> not something that previously existed - there are no rules in the
> Standard that described inheritance for aspects of subprograms

I thought (naively no doubt) that the rules for pre- and post-conditions are
precisely inheritance rules for aspects of subprograms.

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

From: Randy Brukardt
Sent: Wednesday, March 16, 2011  10:33 PM

...
> > Your version seem to have lost the revised 9.5(18/3) that defined
> > the inheritance of the aspects. (This was part of the fixes of this
> > AI, not something that previously existed - there are no rules in
> > the Standard that described inheritance for aspects of subprograms
>
> I thought (naively no doubt) that the rules for pre- and
> post-conditions are precisely inheritance rules for aspects of
> subprograms.

I don't think Pre or Post are inherited at all. There is a rule for Pre'Class
and Post'Class (13.3.2(10/3)) that specifically defines that they "apply" to
descendants, but formally they aren't inherited either (which is why you can
give a new one for them on the descendant).

So that isn't much help. ;-)

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

From: Jean-Pierre Rosen
Sent: Thursday, March 17, 2011  4:13 AM

> Fill in your own ideas here.

Is_Synchronized => Optional

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

From: Gary Dismukes
Sent: Wednesday, April  6, 2011  7:10 PM

This is a wording nit for AI05-0215.

In the !corrigendum, the third instance of "Is_Synchronized aspect"
should be preceded by 'the':

  Modify 9.5(18/3) as follows:

    [A pragma Implemented is said to *apply* to the procedure denoted
    by its *procedure_*local_name.] {Inherited subprograms inherit the
    Is_Synchronized aspect, if any, from the corresponding subprogram of the
    parent or progenitor type.}  If an overriding operation does not have
    a [pragma] {directly specified} Is_Synchronized {aspect} then [any pragma
    Implemented applying to] {Is_Synchronized aspect of} the inherited
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^

{Is_Synchronized aspect of} => {the Is_Synchronized aspect of}

    operation [applies to] {is inherited by} the overriding operation.


And I may as well mention a really small nit wrt the !corrigendum wording for
9.5.4(5.1/3):

  Modify 9.5.4(5.1/3) as follows:

    If the target is a procedure, the name shall denote a rename of an entry,...

I suggest changing "a rename of" to "a renaming of".

While there are a few places in the RM that use the wording "rename of", the
majority say "renaming of", and personally I think the latter sounds better.  I
suppose all the various instances of this wording should be made consistent.  (I'll
understand if you choose to simply ignore this suggestion. :)

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

From: John Barnes
Sent: Thursday, April 7, 2011  6:20 AM

In the following note some typos

Modify 9.5(13/3 - 16/3) as follows:


  For the declaration of a primitive procedure of a synchronized tagged type
  the following language-defined representation aspect may be specified with
  an aspect_specification:
    Is_Synchronized.
      If specified, the aspect definition shall be a Synchronization_Kind.

  The Synchronization_Kind By_Protected_Procedure shall not be applied to
  a primitive procedure of a task interface.

  A procedure for which the specified Synchronization_Kind is By_Entry shall
  be implemented by [a] an entry. A procedure for which the
  specified  Synchronization_Kind is [as] By_Protected_Procedure shall be
  implemented by a protected procedure.

  If a primitive procedure overrides an inherited operation for which the
  Is_Synchronized aspect has been specified, then any specification of the
  aspect Is_Synchronized applied to the overriding operation shall have the
  same Synchronization_Kind, or the inherited Synchronization_Kind shall be
  Optional.


For completeness in the para starting "A procedure" in the above. I would add
something about the poor lonely Optional. eg

A procedure for which the the specified Synchronization_Kind is Optional can
be implemented by an entry or by a procedure (including a protected
procedure).

Maybe it is somthing to do with the battle of Agincourt but I don't like
Optional but much prefer By_Any.  It just has to start By_

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

From: Randy Brukardt
Sent: Thursday, April 7, 2011  9:20 PM

...
> Modify 9.5(13/3 - 16/3) as follows:
...
>   A procedure for which the specified Synchronization_Kind is By_Entry shall
>   be implemented by [a] an entry. A procedure for which the
>   specified  Synchronization_Kind is [as] By_Protected_Procedure shall be
>   implemented by a protected procedure.
...
> For completeness in the para starting "A procedure" in the above. I
> would add something about the poor lonely Optional. eg
>
> A procedure for which the the specified Synchronization_Kind is
> Optional can be implemented by an entry or by a procedure (including a
> protected procedure).

This is a fine idea, but "can" is not allowed in International Standards (by the
drafting rules). We have to use "may" here.

We can use "may", but may not use "can". Similarly, we must use "shall", we shall
not use "must". But we cannot use "may not", and we may not use "cannot".

Easy to remember, right? ;-)

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

From: Tucker Taft
Sent: Monday, May 2, 2011  9:44 PM

[Part of a message appropriate to this AI.]

AI05-0215-1/08  Pragma Implemented should be an aspect, renamed, and better defined
    [The class of this AI was wrong; it modifies an Amendment AI, so it also has to be Amendment.
     Otherwise, it is unchanged.]
    Approve ___X___ Disapprove ______ Abstain _______
   Comments: I prefer the aspect name "Synchronization" to
    "Is_Synchronized".  I think "Synchronization => Optional" is
    significantly nicer than "Is_Synchronized => Optional" and
    "Synchronization => By_Entry/By_Protected_Procedure" also
    reads well.  Finally, it seems more natural for the aspect to
    be "Synchronization" if the corresponding type is "Synchronization_Kind."

    This paragraph is slightly weird:
        If a primitive procedure overrides an inherited operation for which the
	Is_Synchronized aspect has been specified, then any specification of the
	aspect Is_Synchronized applied to the overriding operation shall have
	the same Synchronization_Kind, or the inherited Synchronization_Kind
	shall be Optional.

     It seems odd to create a requirement on the inherited Synchronization_Kind,
     since that is already determined at the point where the operation is being
     overridden.

     To me, it would make more sense to phrase this as follows:
        If a primitive procedure overrides an inherited operation for which the
	Synchronization aspect has been specified to be By_Entry or
	By_Protected_Procedure, then any specification of the aspect
	Synchronization applied to the overriding operation shall have the same
	Synchronization_Kind.

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

From: Randy Brukardt
Sent: Monday, May 2, 2011  10:32 PM

[Part of a message appropriate to this AI.]

...
> AI05-0215-1/08  Pragma Implemented should be an aspect, renamed, and
> better defined
>     [The class of this AI was wrong; it modifies an Amendment AI, so
> it
also has to be Amendment.
>      Otherwise, it is unchanged.]
>     Approve ___X___ Disapprove ______ Abstain _______
>    Comments: I prefer the aspect name "Synchronization" to
>     "Is_Synchronized".  I think "Synchronization => Optional" is
>     significantly nicer than "Is_Synchronized => Optional" and
>     "Synchronization => By_Entry/By_Protected_Procedure" also
>     reads well.  Finally, it seems more natural for the aspect to
>     be "Synchronization" if the corresponding type is "Synchronization_Kind."

Humm, anyone else have a thought on this one?

>     This paragraph is slightly weird:
>         If a primitive procedure overrides an inherited operation for which the
>         Is_Synchronized aspect has been specified, then any specification of the
>         aspect Is_Synchronized applied to the overriding operation shall have the
>         same Synchronization_Kind, or the inherited Synchronization_Kind shall be
>         Optional.
>      It seems odd to create a requirement on the inherited Synchronization_Kind, since
>      that is already determined at the point where the operation is being overridden.
>      To me, it would make more sense to phrase this as follows:
>         If a primitive procedure overrides an inherited operation for which the
>         Synchronization aspect has been specified to be By_Entry or
>         By_Protected_Procedure, then any specification of the aspect Synchronization
>         applied to the overriding operation shall have the same Synchronization_Kind.

OK by me.

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

From: Tucker Taft
Sent: Tuesday, May 3, 2011  7:45 AM

[Part of a message appropriate to this AI.]

...
> Humm, anyone else have a thought on this one?

John Barnes already gave this idea the thumbs up, several weeks ago.

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

From: John Barnes
Sent: Tuesday, May 3, 2011  11:16 AM

I strongly prefer Synchronization. But instead of Optional we could have
Is_Optional or Not_Specified (the latter you (Tuck) suggested earlier.

I did promise to chew over this over Easter. However my mind was on other things
like the old lady I bashed in a car park in Shropshire (actually I only bashed
her motor) and the fact that my beloved wife left her bag in Wales when we
travelled to the Peak district and this meant that a courier had to spend a
happy few hours driving around to get it.

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

From: Randy Brukardt
Sent: Tuesday, May 3, 2011  5:43 PM

...
> I did promise to chew over this over Easter. However my mind was on
> other things ...

Uh-huh. Anyway, I would hope that we are all done chewing from Easter. (Else
that was one tough ham served for Easter dinner. ;-)

What this problem requires is bold decision-making. (OK, not from this group.
:-) I'll set up another one of my famous straw polls to gauge the thinking on
this one.

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

From: Randy Brukardt
Sent: Tuesday, May 3, 2011  6:00 PM

(Sorry about the cryptic subject; it is hard to write a subject for this message
without biasing the results.)

We've previously discussed (without conclusion) possible names for the aspect
defined by AI05-0030-2 and AI05-0215-1. It originally was "Implemented", and it
now has changed into "Is_Synchronized". Part of the problem is that most of the
best names turn out to be reserved words. We're also still unclear on the best
name for the default state of this aspect (note that this name will usually not
appear in program text; it is primarily a wording aid).

Note that the other states are named By_Entry and By_Protected_Procedure, so the
aspect name should work with those names (those will appear in program text).

So I am asking for a quick straw poll on this issue. If needed, AI05-0215-1 will
be modified with the result of this poll. I've gathered up the most interesting
ideas floated so far:

Please rank the top three of the following solutions from 1 (preferred) to 3
(least preferred):

______  The aspect is named Is_Synchronized and the default state is Optional [this is the current definition]

______  The aspect is named Is_Synchronized and the default state is Not_Required

______  The aspect is named Is_Synchronized and the default state is Not_Specified

______  The aspect is named Is_Synchronized and the default state is Perhaps_Not

______  The aspect is named Is_Synchronized and the default state is Who_Cares

______  The aspect is named Is_Synchronized and the default state is By_Any

______  The aspect is named Synchronization and the default state is Optional

______  The aspect is named Synchronization and the default state is Not_Specified

______  The aspect is named Synchronization and the default state is Not_Required

______  The aspect is named _______________ and the default state is ________________

[Editor's note: I suspect that some of these were suggested in jest, but there
is no indication of that in the messages, so I've put them all here for voting.]

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

From: Randy Brukardt
Sent: Tuesday, May 3, 2011  6:02 PM

Here's my ballot:

...
> Please rank the top three of the following solutions from 1
> (preferred) to 3 (least
> preferred):
>
>
> ______  The aspect is named Is_Synchronized and the default state is
> Optional [this is the current definition]
>
> ___3___  The aspect is named Is_Synchronized and the default state is
> Not_Required
>
> ______  The aspect is named Is_Synchronized and the default state is
> Not_Specified
>
> ______  The aspect is named Is_Synchronized and the default state is
> Perhaps_Not
>
> ______  The aspect is named Is_Synchronized and the default state is
> Who_Cares
>
> ______  The aspect is named Is_Synchronized and the default state is
> By_Any
>
> ___2___  The aspect is named Synchronization and the default state is
> Optional
>
> ______  The aspect is named Synchronization and the default state is
> Not_Specified
>
> ___1___  The aspect is named Synchronization and the default state is
> Not_Required
>
> ______  The aspect is named _______________ and the default state is
> ________________

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

From: Bob Duff
Sent: Tuesday, May 3, 2011  6:28 PM

Here are my votes:

> __3___  The aspect is named Is_Synchronized and the default state is
> Optional [this is the current definition]
>
> ______  The aspect is named Is_Synchronized and the default state is
> Not_Required
>
> ______  The aspect is named Is_Synchronized and the default state is
> Not_Specified
>
> ______  The aspect is named Is_Synchronized and the default state is
> Perhaps_Not
>
> ______  The aspect is named Is_Synchronized and the default state is
> Who_Cares
>
> ______  The aspect is named Is_Synchronized and the default state is
> By_Any
>
> __1___  The aspect is named Synchronization and the default state is
> Optional
>
> ______  The aspect is named Synchronization and the default state is
> Not_Specified
>
> __2___  The aspect is named Synchronization and the default state is
> Not_Required
>
> ______  The aspect is named _______________ and the default state is
> ________________

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

From: Tucker Taft
Sent: Tuesday, May 3, 2011  6:33 PM

> Please rank the top three of the following solutions from 1
> (preferred) to 3 (least
> preferred):
>
>
> ______  The aspect is named Is_Synchronized and the default state is
> Optional [this is the current definition]
>
> ______  The aspect is named Is_Synchronized and the default state is
> Not_Required
>
> ______  The aspect is named Is_Synchronized and the default state is
> Not_Specified
>
> ______  The aspect is named Is_Synchronized and the default state is
> Perhaps_Not
>
> ______  The aspect is named Is_Synchronized and the default state is
> Who_Cares
>
> ______  The aspect is named Is_Synchronized and the default state is
> By_Any
>
> ___2___  The aspect is named Synchronization and the default state is
> Optional
>
> ____1__  The aspect is named Synchronization and the default state is
> Not_Specified
>
> ___3___  The aspect is named Synchronization and the default state is
> Not_Required
>
> ______  The aspect is named _______________ and the default state is
> ________________

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

From: Robert Dewar
Sent: Tuesday, May 3, 2011 10:33 PM

> Please rank the top three of the following solutions from 1
> (preferred) to 3 (least
> preferred):
>
>
> __`____  The aspect is named Is_Synchronized and the default state is
> Optional [this is the current definition]
>
> ______  The aspect is named Is_Synchronized and the default state is
> Not_Required
>
> ______  The aspect is named Is_Synchronized and the default state is
> Not_Specified
>
> ______  The aspect is named Is_Synchronized and the default state is
> Perhaps_Not
>
> ______  The aspect is named Is_Synchronized and the default state is
> Who_Cares
>
> ______  The aspect is named Is_Synchronized and the default state is
> By_Any
>
> ______  The aspect is named Synchronization and the default state is
> Optional
>
> ______  The aspect is named Synchronization and the default state is
> Not_Specified
>
> ______  The aspect is named Synchronization and the default state is
> Not_Required
>
> ______  The aspect is named _______________ and the default state is
> ________________
>

I don't have a 2 and a 3, because I don't care, my 1 is simply to say that the
status quo is fine.

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

From: Brad Moore
Sent: Tuesday, May 3, 2011  11:47 PM

Here's my ballot:
> ...
>> Please rank the top three of the following solutions from 1
>> (preferred) to 3 (least
>> preferred):
>>
>>
>> ______  The aspect is named Is_Synchronized and the default state is
>> Optional [this is the current definition]
>>
>> ______  The aspect is named Is_Synchronized and the default state is
>> Not_Required
>>
>> ______  The aspect is named Is_Synchronized and the default state is
>> Not_Specified
>>
>> ______  The aspect is named Is_Synchronized and the default state is
>> Perhaps_Not
>>
>> ______  The aspect is named Is_Synchronized and the default state is
>> Who_Cares
>>
>> ______  The aspect is named Is_Synchronized and the default state is
>> By_Any
>>
>> ___2___  The aspect is named Synchronization and the default state is
>> Optional
>>
>> ___3__  The aspect is named Synchronization and the default state is
>> Not_Specified
>>
>> ___1___  The aspect is named Synchronization and the default state is
>> Not_Required

Choice 3 is a distant 3rd. It seems weird to specify that its not specified.

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

From: Jean-Pierre Rosen
Sent: Wednesday, May 4, 2011  1:59 AM

> Please rank the top three of the following solutions from 1
> (preferred) to 3 (least
> preferred):
>
>
> ___3___  The aspect is named Is_Synchronized and the default state is
> Optional [this is the current definition]
>
> ______  The aspect is named Is_Synchronized and the default state is
> Not_Required
>
> ______  The aspect is named Is_Synchronized and the default state is
> Not_Specified
>
> ______  The aspect is named Is_Synchronized and the default state is
> Perhaps_Not
>
> ______  The aspect is named Is_Synchronized and the default state is
> Who_Cares
>
> ______  The aspect is named Is_Synchronized and the default state is
> By_Any
>
> ___1___  The aspect is named Synchronization and the default state is
> Optional
>
> ______  The aspect is named Synchronization and the default state is
> Not_Specified
>
> ___2___  The aspect is named Synchronization and the default state is
> Not_Required
>
> ______  The aspect is named _______________ and the default state is
> ________________

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

From: John Barnes
Sent: Wednesday, May 4, 2011  6:26 AM

> Please rank the top three of the following solutions from 1
> (preferred) to
> 3
> (least
> preferred):
>
>
> ______  The aspect is named Is_Synchronized and the default state is
> Optional [this is the current definition]
>
> ______  The aspect is named Is_Synchronized and the default state is
> Not_Required
>
> ______  The aspect is named Is_Synchronized and the default state is
> Not_Specified
>
> ______  The aspect is named Is_Synchronized and the default state is
> Perhaps_Not
>
> ______  The aspect is named Is_Synchronized and the default state is
> Who_Cares
>
> ______  The aspect is named Is_Synchronized and the default state is
> By_Any
>
> ___3___  The aspect is named Synchronization and the default state is
> Optional
>
> ___1___  The aspect is named Synchronization and the default state is
> Not_Specified
>
> ___2___  The aspect is named Synchronization and the default state is
> Not_Required
>
> ______  The aspect is named _______________ and the default state is
> ________________
>

Glancing at other ballots, it looks at least as if we have got rid of the Is
which makes me happy so that I can remove Rant 2 from the Rat.

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

From: Randy Brukardt
Sent: Friday, May 6, 2011  1:59 PM

Here is the results so far on the synch aspect vote. We have a tie at this point
(two choices both got 2 first place votes, 3 second place votes, and 1 third
place votes), and it is pretty clear that the other choices are not going to
matter. OTOH, quite a few people (Gary, Steve, Erhard) did not vote that usually
do. So I'm going to ask for a second straw poll to decide between the tied
options:

--------

Please chose one of the following:

_______  The aspect is named Synchronization and the default state is Optional

_______  The aspect is named Synchronization and the default state is Not_Required


-------------------------


> Please rank the top three of the following solutions from 1
> (preferred) to 3 (least preferred): [7 overall votes; note that one
> ballot did not give options 2 and 3.]
>
>
> __3_1_3__  The aspect is named Is_Synchronized and the default state
> is Optional [this is the current definition]
>
> __3____  The aspect is named Is_Synchronized and the default state is
> Not_Required
>
> ______  The aspect is named Is_Synchronized and the default state is
> Not_Specified
>
> ______  The aspect is named Is_Synchronized and the default state is
> Perhaps_Not
>
> ______  The aspect is named Is_Synchronized and the default state is
> Who_Cares
>
> ______  The aspect is named Is_Synchronized and the default state is
> By_Any
>
> __2_1_2_2_1_3_  The aspect is named Synchronization and the default
> state is Optional
>
> __1_3_1___  The aspect is named Synchronization and the default state
> is Not_Specified
>
> __1_2_3_1_2_2_  The aspect is named Synchronization and the default
> state is Not_Required
>
> ______  The aspect is named _______________ and the default state is
> ________________

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

From: Randy Brukardt
Sent: Friday, May 6, 2011  1:59 PM

And my ballot:

Please chose one of the following:

________  The aspect is named Synchronization and the default state is Optional

___X____  The aspect is named Synchronization and the default state is Not_Required

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

From: Tucker Taft
Sent: Friday, May 6, 2011  2:09 PM

> Please chose one of the following:
>
> ___X____  The aspect is named Synchronization and the default state is
> Optional
>
> _______  The aspect is named Synchronization and the default state is
> Not_Required
>

I believe if you look up the definition of "optional"
you will find it means "not required."  So it seems silly to use the longer
phrase.

I personally preferred  "Not_Specified" but I guess that didn't make the cut...

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

From: Steve Baird
Sent: Friday, May 6, 2011  2:26 PM

> I believe if you look up the definition of "optional"
> you will find it means "not required."  So it seems silly to use the
> longer phrase.

I'll also vote for "optional", but to say that I don't feel strongly about this
one is an understatement.

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

From: John Barnes
Sent: Friday, May 6, 2011  2:33 PM

> Please choose one of the following:
>
> _______  The aspect is named Synchronization and the default state is
> Optional
>
> ____X___  The aspect is named Synchronization and the default state is
> Not_Required

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

From: Edmond Schonberg
Sent: Friday, May 6, 2011  2:38 PM

> I'll also vote for "optional", but to say that I don't feel strongly
> about this one is an understatement.
>

Ditto, shorter is better

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

From: Gary Dismukes
Sent: Friday, May 6, 2011  2:40 PM

> Please chose one of the following:

chose => choose

> ___X___  The aspect is named Synchronization and the default state is
> Optional
>
> _______  The aspect is named Synchronization and the default state is
> Not_Required

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

From: Bob Duff
Sent: Friday, May 6, 2011  2:54 PM

> Please chose one of the following:
>
> __X____  The aspect is named Synchronization and the default state is
> Optional
>
> _______  The aspect is named Synchronization and the default state is
> Not_Required

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

From: Jean-Pierre Rosen
Sent: Friday, May 6, 2011  4:10 PM

> Please chose one of the following:
>
> ___1____  The aspect is named Synchronization and the default state is
> Optional
>
> ____2___  The aspect is named Synchronization and the default state is
> Not_Required

Just because I thought that making them ex-aequo would not help.

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

From: Brad Moore
Sent: Friday, May 6, 2011  7:25 PM

> Please chose one of the following:
>
> _____X__  The aspect is named Synchronization and the default state is
> Optional
>
> _______  The aspect is named Synchronization and the default state is
> Not_Required

I'm thinking it's better to say what it is, than what it isnt

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

From: Erhard Ploedereder
Sent: Monday, May 9, 2011  11:52 AM

Please chose one of the following:

___X____  The aspect is named Synchronization and the default state is Optional

_______  The aspect is named Synchronization and the default state is Not_Required


Erhard (who usually stays out of naming discussions, only to regret it later ;-)

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

From: Randy Brukardt
Sent: Thursday, May 12, 2011  1:00 AM

To summarize the results of this second straw poll:

Please chose one of the following:

___8____  The aspect is named Synchronization and the default state is Optional

___2____  The aspect is named Synchronization and the default state is Not_Required

This is a pretty clear-cut result, and I've updated the AI to reflect this. Thanks for voting.

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

From: Randy Brukardt
Sent: Thursday, May 12, 2011  1:52 AM

A for-the-record note:

AI05-0060-1 adds a rule to the DS annex about "pragma Implemented". This needs
to be changed to aspect Synchronization as with all of the other references
originally from AI05-0030-2. (Another case of the tools complaining about
something; as Bob notes, there is a bit of regression testing in the Standard,
at least as far as syntax is concerned.)

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

From: Erhard Ploedereder
Sent: Sunday, May 15, 2011  11:31 AM

[The appropriate part of a longer message - Editor]

AI05-0215-1/08  Pragma Implemented should be an aspect, renamed, and better defined
   [The class of this AI was wrong; it modifies an Amendment AI, so it also has to be Amendment.
    Otherwise, it is unchanged.]
   Approve ______ Disapprove __ X ____ Abstain _______

============

Why doesn't 9.5(18/3) simply say: "The Synchonization aspect is inherited by
derived types." ?

The current verbage is rather confusing, since the neded other part of it is in 16/3.
Here is the draft of a(n erroneous) comment that I was led to by 18/3:
------
I am surprised that 9.5(18/3) seems to allow that By_Protected_Procedure can become
By_Entry in a redefining declaration. Is this really intended, so that I call on a
routine that promises no barrier and then the redefining routine does block after all?
Not good!
-------
I know now that 16/3 prevents it, but why this completely convoluted way of saying
"is an inheritable aspect"?

I am unconfortable with the term "Optional" in this context after all, since
"Synchronization = Optional" definitely reads as if synchronization were optional,
which of course is completely contradictory to the restriction to protected operations.
(To my shame, I was misled into a different semantics by the "Not_Required"
as alternative in the poll, since I presumed that finally normal subprograms renaming
entries could get this aspect to communicate their important synchronization property.
Well, fooled me.)

 "Synchronization_Kind =Optional" would be semi-ok.
 "Synchronization =By_Any" sounds much better to me, now in context.

The title of the AI should be made matching the content.

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

From: Gary Dismukes
Sent: Monday, May 16, 2011  4:40 PM

[The appropriate part of a longer message - Editor]

> AI05-0215-1/08  Pragma Implemented should be an aspect, renamed, and
> better defined
>    [The class of this AI was wrong; it modifies an Amendment AI, so it
> also has to be Amendment.
>     Otherwise, it is unchanged.]
>    Approve ______ Disapprove ______ Abstain __X____

[Comment: I find myself tending to agree with Erhard's comment regarding
Optional vs. By_Any, though not enough to vote for disapproval.

 Erhard said:

  I am unconfortable with the term "Optional" in this context after all,
  since "Synchronization = Optional" definitely reads as if
  synchronization were optional, which of course is completely
  contradictory to the restriction to protected operations.  (To my
  shame, I was misled into a different semantics by the "Not_Required"
  as alternative in the poll, since I presumed that finally normal
  subprograms renaming entries could get this aspect to communicate
  their important synchronization property. Well, fooled me.)

   "Synchronization_Kind =Optional" would be semi-ok.
   "Synchronization =By_Any" sounds much better to me, now in context.

end of Comment]

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

From: Randy Brukardt
Sent: Tuesday, May 17, 2011  1:52 AM

> AI05-0215-1/08  Pragma Implemented should be an aspect, renamed, and
> better defined
>    [The class of this AI was wrong; it modifies an Amendment AI, so it also has to be Amendment.
>     Otherwise, it is unchanged.]
>    Approve ______ Disapprove __ X ____ Abstain _______
>
> ============
>
> Why doesn't 9.5(18/3) simply say: "The Synchonization aspect is
> inherited by derived types." ?

Because this is an aspect of a subprogram, not of a type. Only types inherit
aspects, subprograms never do. ("Subprogram" is never mentioned in 13.1(15/1)!).

We could have defined inheritance of subprogram aspects, but since we didn't
want most of them to be inherited, it would have made things messier. So the two
aspects that do have a form of inheritance define it themselves.

> The current verbage is rather confusing, since the neded other part of
> it is in 16/3. Here is the draft of a(n
> erroneous) comment that I was led to by 18/3:
> ------
> I am surprised that 9.5(18/3) seems to allow that
> By_Protected_Procedure can become By_Entry in a redefining
> declaration. Is this really intended, so that I call on a routine that
> promises no barrier and then the redefining routine does block after
> all? Not good!
> -------
> I know now that 16/3 prevents it, but why this completely convoluted
> way of saying "is an inheritable aspect"?

Because there are no "inheritable aspects" for subprograms.

Also note that the two rules in question are separated because one is static
semantics and one is a legality rule. Also note that your editor reversed these
rules when he put this text into the Standard, because it otherwise had two
static semantics sections separated by some legality rules. And it now puts the
more important rule first.

> I am unconfortable with the term "Optional" in this context after all,
> since "Synchronization = Optional" definitely reads as if
> synchronization were optional, which of course is completely
> contradictory to the restriction to protected operations.

I have absolutely no idea what you are talking about here. What "restriction to
protected operations"?? There is none required by this aspect! It definitely
allows completion by normal subprograms, just as any primitive operation of a
synchronized interface does in Ada 2005. That's necessary for compatibility,
at a minimum.

I note Gary seemed to think this was significant as well, which indicates to me
that either I (and a number of others) have missed something fundamental, or a
number of people are very confused about synchronized interfaces.

> (To my shame, I was misled into a different semantics by the
> "Not_Required"
> as alternative in the poll, since I presumed that finally normal
> subprograms renaming entries could get this aspect to communicate
> their important synchronization property. Well, fooled me.)

I'm actually a bit surprised that we don't allow this aspect on all subprograms,
but that's something to discuss in the future. In any case, a renaming does not
have aspects of it's own; "By_Entry" is an unnamed property of a renamed much as
"constant" is an unnamed property. It's arguable whether this was a good idea,
but the mistake was made by Jean in the Paleozoic era of Ada, and its just a wee
bit late to fix now.

>  "Synchronization_Kind =Optional" would be semi-ok.
>  "Synchronization =By_Any" sounds much better to me, now in context.

A normal subprogram has no synchronization at all; By_Any implies (to me, at
least) that the primitive routine does -- but that is clearly not required.

> The title of the AI should be made matching the content.

It is. "Pragma Implemented should be an aspect, renamed, and better defined"
I had to shorten it a bit: "Pragma Implemented should be an aspect rather than a
pragma, renamed to Synchronization, and better defined" would be better, but it
is way too long for our tools. And keep in mind that this AI is changing an
existing AI that defines "pragma Implemented", so not mentioning that at all
seems wrong to me. Finally, the original reason for this AI was to fix bugs in
pragma Implemented; the other things came later and not mentioning them at all
seems wrong as well.

"Pragma Implemented should be replaced by aspect Synchronization, and the
definition improved" might be better, but it is still too long. And "replaced
by" isn't quite what's happening here.

Anyway, better suggestions welcome.

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

Questions? Ask the ACAA Technical Agent