!standard 6.1.2(10/5) 19-03-04 AI12-0310-1/03 !standard 6.1.2(33/5) !reference AI12-0079-1 !class Amendment 19-02-06 !status Amendment 1-2012 19-02-11 !status ARG Approved 10-0-0 19-02-11 !status work item 19-02-06 !status received 19-01-31 !priority Low !difficulty Easy !subject Specifying private parts of packages in aspect Global !summary The syntax for specifying private parts of packages for aspect Global is "private of ". !problem The syntax of global_names (part of the syntax for the global aspect) reads: global_name ::= object_name | package_name [ private ] | access_subtype_mark | access subtype_mark Note that "Private" *follows* the name of the package. So correct syntax (according to these rules) is something like: Global => in out synchronized Text_IO private; This is weird. !proposal (See Summary.) !wording Replace 6.1.2(10/5) with: global_name ::= /object_/name | [*private of*] /package_/name | /access_/subtype_mark | ACCESS subtype_mark Modify 6.1.2(33/5): * /package_/name identifies the set of all variables declared within the declarative region of the package having the same accessibility level as the package, but not including those within the declarative region of a public child of the package; if the reserved word{s} *private{ of}* {precede}[follows] the /package_/name, the set is reduced to those variables declared in the private part or body of the package or within a private descendant of the package; !discussion Just putting "private" in front of the package name seems to imply adding the private part to the visible part, while it actually restricts the objects to those in the private part (and body) of the package. Thus we insert "of" to hopefully clarify the meaning. The Global aspect in the !problem will now be written: Global => in out synchronized private of Text_IO; !corrigendum 6.1.2(0) @dinsc Dummy to force a conflict; the wording changes are in the conflict file. !ASIS No change needed. !ACATS test This will be covered by typical ACATS tests for Global, so separate testing is not needed (and we do not test syntax rules in general). !appendix From: Randy Brukardt Sent: Thursday, January 31, 2019 11:39 PM Putting AI12-00790-1 into the RM means I've read it carefully for the first time in forever. The syntax of global_names (part of the syntax for the global aspect) reads: global_name ::= object_name | package_name [ private ] | access_subtype_mark | access subtype_mark Note that "Private" *follows* the name of the package. So correct syntax (according to these rules) is something like: Global => in out synchronized Text_IO private; Am I the only one that finds this weird? Most (all?) of the existing uses of "private" are before the thing that they modify: private with Text_IO; private package Ada.Strings.Goodies is ... So here I would have expected "private" to come before the package name: Global => in out synchronized private Text_IO; That is, I would have expected that the syntax would be: | [private ]package_name I don't know if there is any syntactic reason for this order (I can't find any). (Not sure why there are so many spaces in the original syntax, either -- we're supposed to be showing preferred style with the syntax rules, and lots of extra spaces don't seem to be required.) I don't see any examples with this keyword, which is probably why I didn't notice this earlier. Thoughts?? **************************************************************** From: Tucker Taft Sent: Friday, February 1, 2019 11:42 AM I guess I am OK with moving "private" before the package name. But note that it has a somewhat different meaning than in a "with private" clause, in that we are saying that we are using as globals the private part of Text_IO, rather than "with-ing" (all of) Text_IO only in the private part of the client. And in the private child case, it is saying that Text_IO itself is private, which is clearly not what we are saying here. So putting it afterward is sort of like saying "Text_IO.", and component selection does come after the package name in Ada. Perhaps "Text_IO.private" would be clearer? **************************************************************** From: Richard Wai Sent: Friday, February 1, 2019 12:40 PM Looking through the AI pretty quickly, it almost seems as if private would be more naturally a member of global_mode_qualifier. I know this is a bit problematic since it only applies to packages, but "Global => private in out Text_IO" seems to me to communicate the actual meaning most clearly. Saying "Global => in out Text_IO.private" seems like it breaks a lot of conventions.. If we'd go that route, I wonder if "Text_IO'Private" would be more in-line with the status quo.. Though I'm not sure I like that much either. **************************************************************** From: Steve Baird Sent: Friday, February 1, 2019 12:44 PM > Saying "Global => in out Text_IO.private" seems like it breaks a lot > of conventions.. If we'd go that route, I wonder if "Text_IO'Private" > would be more in-line with the status quo.. Though I'm not sure I like > that much either. I agree on all counts. **************************************************************** From: Tucker Taft Sent: Friday, February 1, 2019 12:48 PM Text_IO'Private actually has something going for it. The problem with "private in out" is that it extends then to all in-out globals listed. I think keeping the word private next to the package name is important. Your suggestion of Text_IO'Private solves several problems in my view. **************************************************************** From: Randy Brukardt Sent: Friday, February 1, 2019 2:42 PM > Looking through the AI pretty quickly, it almost seems as if private > would be more naturally a member of global_mode_qualifier. I know this > is a bit problematic since it only applies to packages, but "Global => > private in out Text_IO" seems to me to communicate the actual meaning > most clearly. I agree, but there would be an issue in that one might want to combine "private" and "synchronized". > Saying "Global => in out Text_IO.private" seems like it breaks a lot > of conventions.. If we'd go that route, I wonder if "Text_IO'Private" > would be more in-line with the status quo.. Though I'm not sure I like > that much either. I agree fully here (I hate .private and I can barely tolerate 'private). **************************************************************** From: Randy Brukardt Sent: Friday, February 1, 2019 2:44 PM > Text_IO'Private actually has something going for it. > > The problem with "private in out" is that it extends then to all > in-out globals listed. I think keeping the word private next to the > package name is important. Your suggestion of Text_IO'Private solves > several problems in my view. OK, I'll draft a clean-up AI to that effect and we can then discuss it in a meeting forum. **************************************************************** From: Richard Wai Sent: Friday, February 1, 2019 2:58 PM > I agree fully here (I hate .private and I can barely tolerate 'private). I have one other maybe controversial idea: "Global => in out Text_IO with private" **************************************************************** From: Tucker Taft Sent: Friday, February 1, 2019 3:20 PM I could feel that coming on ;-), but that syntax would imply you are referring to both Text_IO and its private declarations, when in fact you are referring to *only* the private (stateful) declarations. For the visible state (if there were any), you are indicating that you will be more specific. I suppose "Text_IO in private" could communicate something interesting ... ;-) **************************************************************** From: Richard Wai Sent: Friday, February 1, 2019 3:26 PM > I could feel that coming on ;-), but that syntax would imply you are > referring to both Text_IO and its private declarations, when in fact you > are referring to *only* the private (stateful) declarations. For the > visible state (if there were any), you are indicating that you will be > more specific. This is exactly what came to mind just after hitting send. I think that makes it DoA... > I suppose "Text_IO in private" could communicate something interesting ... > ;-) Now we're getting dangerous! (Mutters under breath *how about private of Text_IO?*) **************************************************************** From: Randy Brukardt Sent: Friday, February 1, 2019 3:26 PM > I have one other maybe controversial idea: "Global => in out Text_IO > with private" That seems backwards, it sounds like it's including private when it really is excluding the visible part. It's more like: Global => in out Text_IO with private only or just Global => in out Text_IO private only but of course "only" isn't a reserved word. Global => in out Text_IO private part Global => in out private part of Text_IO but "part" isn't a reserved word, either. Seems like everything sucks, so we need to chose something and live with it. I suppose Text_IO'private works as well as anything. (Wonder if we should have Text_IO'all as an option to specify that you meant everything? I'm not a fan of using the absence something to be meaningful.) **************************************************************** From: Randy Brukardt Sent: Friday, February 1, 2019 4:02 PM > (Mutters under breath *how about private of Text_IO?*) Not sure why I didn't think of that. I like it! Also not sure why the mailing list is taking 15+ minutes to deliver messages. Will investigate. **************************************************************** From: Jean-Pierre Rosen Sent: Friday, February 1, 2019 4:53 PM > I have one other maybe controversial idea: "Global => in out Text_IO > with private" Hmm... If you want to play with reserved words, I think that the closest to the idea would be "Global => in out private of Text_IO" ****************************************************************