!standard 9.5(10-18/3) 11-03-17 AI05-0215-1/04 !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 Pragma Implemented should be an aspect (and better defined) !summary The aspect Is_Synchronized 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 | By_Any 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 Synchronization_Kind has been specified, then any specification of the Aspect Is_Synchronized applied to the overring operation shall have the same Synchronization_Kind, or the inherited Synchronization_Kind shall be By_Any. 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 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 Implemented pragma] {the Is_Synchronized aspect shall be specified} with [implementation_kind]{Synchronization_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. **************************************************************** 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. ;-) ****************************************************************