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

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

!standard 9.5(18/3)          10-10-25 AI05-0215-1/01
!standard 9.5.4(3/3)
!standard 9.5.4(5/3)
!standard 9.5.4(5.1/3)
!class binding interpretation 10-06-12
!status work item 10-06-12
!status received 10-03-26
!priority Low
!difficulty Easy
!qualifier Omission
!subject Errors in AI05-0030-2
!summary
*** TBD ***
!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).
!recommendation
(See Summary.)
!wording
Modify 9.5(18/3) as follows:
A pragma Implemented {is a representation pragma, and} is [said to apply to]{specifies the Implemented aspect of} 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.
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 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] {the} Implemented [pragma] {aspect shall be specified} with implementation_kind By_Entry [shall apply to] {for} the primitive subprogram.
!discussion
!ACATS Test
!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.

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


Questions? Ask the ACAA Technical Agent