Version 1.5 of ai12s/ai12-0375-1.txt

Unformatted version of ai12s/ai12-0375-1.txt version 1.5
Other versions for file ai12s/ai12-0375-1.txt

!standard 6.1.2(0/5)          20-04-29 AI12-0375-1/02
!class Amendment 20-03-24
!status Amendment 1-2012 20-04-29
!status WG9 Approved 22-06-22
!status ARG Approved 13-0-1 20-04-29
!status work item 20-03-24
!status received 20-03-24
!priority Low
!difficulty Easy
!subject Meaning of Global when there is no mode
!summary
The global mode cannot be omitted before All or Synchronized
!problem
The syntax for the Global aspect is in part:
global_aspect_definition ::= null | Unspecified | global_group_designator | global_mode global_designator | (global_aspect_element{, global_aspect_element}) | extended_global_aspect_definition -- see H.7
global_designator ::= global_group_designator | global_name
global_group_designator ::= all | synchronized
This allows All and Synchronized to appear without a global_mode. However, there is no rule that explains what these mean when the mode is omitted.
!proposal
(See Summary.)
!wording
Replace the global_aspect_definition and global_designator grammar in AI12-0079-3 with:
global_aspect_definition ::= null | Unspecified | global_mode global_designator | (global_aspect_element{, global_aspect_element}) | extended_global_aspect_definition -- see H.7
global_designator ::= all | synchronized | global_name
!discussion
We could have added a line to the Static Semantics like:
If a global_aspect_definition consists of a single global_group_designator, the global_mode is implicitly IN OUT.
However, some reviewers thought it was unusual to have the mode default to IN OUT when it defaults to IN in other cases. Since the case where the mode would be IN is less likely than the case where the mode would be IN OUT, such a shorthand would be more confusing than simplifying. Thus we require the mode to be given.
!corrigendum 6.1.2(0)
Insert new clause:
Dummy to force a conflict; the wording changes are in the conflict file.
!ASIS
[Not sure. It seems like some new capabilities might be needed, but I didn't check - Editor.]
!ACATS test
ACATS B- and C-Tests are needed to check that the new capabilities are supported.
!appendix

From: Randy Brukardt
Sent: Sunday, March 22, 2020  8:08 PM

[From a thread in AI12-0079-3:]

Tucker also noticed that we're missing a rule. If the user writes Global => all 
or Global => synchronized the intent was to interpret that as "in out all" or 
"in out synchronized". He suggested adding the following to the paragraph 
immediately following the BNF:

  If a global_aspect_definition consists of a single global_group_designator,
  the global_mode is implicitly IN OUT.

This second change seems to be a clear oversight that should not be 
controversial, so I am processing it as an Editorial Review change.

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

From: Claire Dross
Sent: Monday, March 23, 2020  8:57 AM

> This second change seems to be a clear oversight that should not be 
> controversial, so I am processing it as an Editorial Review change.

I am not thrilled by this one. Usual default is *in* (for subprogram 
parameters for example), I would find it more consistent to stick with 
that.

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

From: Bob Duff
Sent: Monday, March 23, 2020  9:35 AM

I admit I haven't followed the global thing closely, but I think I agree 
with Claire on this point.

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

From: Richard Wai
Sent: Monday, March 23, 2020  9:39 AM

I agree with Claire. I don't think making in out default is worth it to 
avoid having to always write "in out all/synchronized"

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

From: Tucker Taft
Sent: Monday, March 23, 2020  10:11 AM

> I am not thrilled by this one. Usual default is *in* (for subprogram 
> parameters for example), I would find it more consistent to stick with that.

I would eliminate the default completely if we cannot agree on IN OUT.  
"Global => All" or "Global => Synchronized" have been used in several examples 
to indicate all access, or all synchronized access.  For them to mean 
read-only access would be counterintuitive to me, so I would argue for 
requiring explicit modes if you find this shorthand to be ambiguous.

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

From: Tullio Vardanega
Sent: Monday, March 23, 2020  10:28 AM

I am with Tuck on this one.

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

From: Brad Moore
Sent: Monday, March 23, 2020  8:58 PM

Myself as well...

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

From: Randy Brukardt
Sent: Monday, March 23, 2020  9:16 PM

[Rewriting lost mail...]

...
> I would eliminate the default completely if we cannot agree on IN OUT.  
> "Global => All" or "Global => Synchronized" have been used in several 
> examples to indicate all access, or all synchronized access.  For them 
> to mean read-only access would be counterintuitive to me, so I would 
> argue for requiring explicit modes if you find this shorthand to be 
> ambiguous.

I agree with Tuck (and Tullio).

It seems that "in out all" will be substantially more common than "in all" 
(esp. as there is no package-level way to specify groups of globals). It 
doesn't make a ton of sense to have a short-hand for the less likely case.

Anyway, since this topic obviously is not the "obvious oversight" that I 
expected, I've split it out into a separate AI and we can consider it 
properly. It's clearly isn't something that should get stuck in by editorial 
review.

P.S. Our area is going to be locked-down starting tomorrow, so I won't be 
able to get into the office to do Ada-Auth.org website updates, or to 
moderate or otherwise rescue your e-mail. The lists and website should be 
able to run on their own (much like they do when I'm on vacation).

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

From: Jeff Cousins
Sent: Wednesday, March 25, 2020  2:07 PM

Sorry, but to be clear, when people say that they agree with Tuck, do they 
mean his first option, i.e. the default should be “in out all” or his 
second option, that there should be no default and explicit modes are 
required

?

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

From: Randy Brukardt
Sent: Wednesday, March 25, 2020  2:19 PM

Yes. ;-)

I'm OK with either, but i'm assuming the first will not fly. So I wrote it 
up to remove the ability to have a default mode. See the posted AI12-0375-1.

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

From: Tucker Taft
Sent: Wednesday, March 25, 2020  2:25 PM

I interpreted it to mean that a default of "in" would be confusing, so we 
should remove the default as an option, and require an explicit specification
in all cases, including for "all" and "synchronized."

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

From: Tullio Vardanega
Sent: Wednesday, March 25, 2020  2:43 PM

That's what I meant.

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

From: Jeff Cousins
Sent: Wednesday, March 25, 2020  3:01 PM

Thanks for the clarification.

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

From: Brad Moore
Sent: Thursday, March 26, 2020  2:02 PM

I meant that I agreed with Tucks argument, I didn't state a preference over 
sticking with Tuck's original suggestion as "in out" or removing the default,
only that if we cant agree on "in out", we should remove the default. I 
haven't made up my mind between those two  yet, but either of these two 
options would be preferable to me over going with "in".

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

Questions? Ask the ACAA Technical Agent