Version 1.12 of ai12s/ai12-0330-1.txt

Unformatted version of ai12s/ai12-0330-1.txt version 1.12
Other versions for file ai12s/ai12-0330-1.txt

!standard N(0)          21-03-14 AI12-0330-1/07
!class Amendment 19-04-05
!status Amendment 1-2012 19-05-09
!status ARG Approved 14-0-1 20-12-09
!status work item 20-11-20
!status ARG Approved 11-0-0 19-05-09
!status work item 19-04-05
!status received 19-03-08
!priority Low
!difficulty Easy
!subject Add items to the Glossary
!summary
Various new and preexisting terms are added to the glossary.
!problem
We've defined a number of new concepts in Ada 2020, among them "parallel constructs", "logical thread of control", "reduction", "default initial condition", and "stable property". At least some of these should be added to the Glossary.
!proposal
(See Summary.)
!wording
Modify 9(1/5) to italicize "logical thread of control":
The execution of an Ada program consists of the execution of one or more tasks. Each task represents a separable activity that proceeds independently and concurrently between the points where it interacts with other tasks. A single task, when within the context of a parallel construct, can represent multiple logical threads of control which can proceed in parallel; in other contexts, each task represents one logical thread of control.
Add the following Glossary entries:
Accessibility level An accessibility level is a representation of the lifetime of an entity in terms of the level of dynamic nesting within which the entity is known to exist. Dynamic accessibility checks ensure that a reference does not outlive the entity to which it refers, by checking that the level of the entity is no deeper than the level of the reference. Based on static nesting, there are corresponding legality rules that the level of the entity is not statically deeper than that of the reference.
Aggregate An aggregate is a construct used to define a value of a composite type by specifying the values of the components of the type.
Attribute An attribute is a characteristic or property of an entity that can be queried, and in some cases specified.
Container aggregate A container aggregate is a construct used to define a value of a type that represents a collection of elements, by explicitly specifying the elements in the collection.
Check A check is a test made during execution to determine whether a language rule has been violated.
Default Initial Condition A default initial condition is a property that holds for every default-initialized object of a given type.
Iterator Filter An iterator filter is a construct that is used to restrict the elements produced by an iteration to those for which a boolean condition evaluates to True.
Logical Thread of Control A logical thread of control is an activity within the execution of a program that can proceed in parallel with other activities of the same task, or of separate tasks.
Master A master is the execution of certain constructs. Each object and task is associated with a master. When a master is left, associated objects are finalized and associated tasks are awaited.
Nominal subtype The nominal subtype of a view of an object is the subtype specified when the view is defined.
Operational Aspect An operational aspect is an aspect that indicates a logical property of an entity, such as the precondition of a subprogram, or the procedure used to write a given type of object to a stream.
parallel Construct A parallel construct is an executable construct that defines multiple activities of a single task that can proceed in parallel, via the execution of multiple logical threads of control.
Reduction Expression A reduction expression is an expression that defines how to map or transform a collection of values into a new set of values, and then summarize the values by applying an operation to reduce the set to a single value.
Representation Aspect A representation aspect is an aspect that indicates how an entity is mapped onto the underlying hardware, for example the size or alignment of an object.
Stable Property A stable property is a characteristic associated with objects of a given type that is preserved by many of the primitive operations of the type.
Subunit A subunit is a body of a program unit that can be compiled separately from its enclosing program unit.
Suppress To suppress a check is to assert that the check cannot fail, and to request that the compiler optimize by disabling the check. The compiler is not required to honor this request. Suppressing checks that can fail can cause a program to behave in arbitrary ways.
!discussion
We tried to cover the interesting new concepts, as well as some existing concepts that were not previously defined in the glossary.
We might want to verify that most of these terms also appear in the index. At the moment, "logical thread of control" is not in the index.
!corrigendum 9(1/3)
Replace the paragraph:
The execution of an Ada program consists of the execution of one or more tasks. Each task represents a separate thread of control that proceeds independently and concurrently between the points where it interacts with other tasks. The various forms of task interaction are described in this clause, and include:
by:
The execution of an Ada program consists of the execution of one or more tasks. Each task represents a separable activity that proceeds independently and concurrently between the points where it interacts with other tasks. A single task, when within the context of a parallel construct, can represent multiple logical threads of control which can proceed in parallel; in other contexts, each task represents one logical thread of control.
!comment We're not bothering to make !corrigendum text for the glossary entries.
!ASIS
No ASIS effect.
!ACATS test
No ACATS tests needed.
!appendix

From: Randy Brukardt
Sent: Friday, March 8, 2019  7:39 PM

>Annex N I would like more items, such as Attribute, Check, Master, 
>Operational Aspect, Representation Aspect, Subunit, Suppress.  But I 
>think I had Annex N to review for Ada 2012 too and my request was 
>turned down then.

Some of those terms might be valuable, but I'd guess it would be even more 
useful to add some terms around parallel constructs, like say, "parallel 
construct" :-), "logical thread of control", and "reduction".

Do we have someone volunteering to propose some additional Glossary entries 
(including the definitions, silly :-)??

P.S. I believe that Jeff is away on "holiday", so we can't talk him into it 
today.

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

From: Jeff Cousins
Sent: Thursday, April 4, 2019  8:49 PM

> You're right, of course, but we need Glossary entries for lots of things 
and I didn't get any volunteers when I asked last month.
 
Here’s a shot at the items that I suggested.  No doubt as everyone knows a 
bit about this everyone will comment.
 
Attribute
A characteristic or property of an entity that can be queried, and in some 
cases specified.  (I daren’t tackle how this overlaps with aspect!).

Check
A test made during execution that some unusual condition has not occurred.

Master
The execution of a construct that includes the finalisation of local objects 
(after completion but before leaving).

Operational Aspect
Aspects other than Representation Aspects.

Representation Aspect
An aspect that affects how an entity is mapped onto the underlying hardware, 
for example the size or alignment of an object.

Subunit
A body that can be compiled separately from its embracing library unit. (Only 
GNAT doesn’t ? ).

Suppress
To turn off a run-time check.

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

From: Randy Brukardt
Sent: Thursday, April 4, 2019  8:49 PM

Great, but that doesn't include anything NEW, which seems to be the most 
critical need.

Ed asked for "default initial condition", presumably because all of the other 
assertion contracts already have a glossary entry (and that was obvious in the 
text he was reviewing 

I had suggested at a minimum "parallel construct", "logical thread of 
control", and "reduction". There may be others.

P.S. I need to know where to place the entries as well. Glossary entries are 
actually given in as AARM notes next to the formal definition (scattered about 
the Standard); the tools make the actual annex at the end. Side thought: it's 
a bit annoying that the information about the location of the formal definition 
isn't displayed in the glossary, since that wouldn't be very hard to do, at 
least in non-ISO editions.

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

From: Randy Brukardt
Sent: Friday, April 5, 2019  11:02 PM

...
>Here’s a shot at the items that I suggested.  No doubt as everyone 
>knows a bit about this everyone will comment.

So far this message has gotten the same response as the original call for a 
volunteer. I suppose that says something too.
	 
...
>Master
>
>The execution of a construct that includes the finalisation of local 
>objects (after completion but before leaving).

We just had a long discussion of 's' vs. 'z' in "finalization". Hope we don't 
have another one. :-)

>Operational Aspect
>Aspects other than Representation Aspects.

Not strictly true, there are a few that aren't officially classed as either. 
If they have enough rules (like "Pre"), that doesn't matter. In any event, 
this is rather circular. It should say something about properties, as in 
13.1. Maybe:

An aspect that defines properties of an entity other than representation 
properties (see Representation Aspect).
	 
>Subunit
>A body that can be compiled separately from its embracing library unit.  
>(Only GNAT doesn’t ? ).

I'm pretty sure we can't put emojies into the Standard; probably can't refer 
to GNAT either. ;-)

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

From: Jeff Cousins
Sent: Saturday, April 6, 2019  3:49 AM

>>The execution of a construct that includes the finalisation of local objects 
>>(after completion but before leaving).

>We just had a long discussion of 's' vs. 'z' in "finalization". Hope we don't 
have another one. :-)
 
I’d deliberately typed ‘z’ in deference to my American colleagues, but the 
spell-checker must have auto-corrected it.

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

From: Jeff Cousins
Sent: Saturday, April 6, 2019  12:04 PM

> Great, but that doesn't include anything NEW, which seems to be the 
> most critical need.
 
I actually see the newer terms as being less important as they're for the more 
advanced users, whereas some of the older terms are building blocks for how 
Ada views the world, and should have been in the glossary years ago.

I would prefer the authors of the relevant AIs to state their intended 
meaning rather than me potentially second-guessing them, but I've had a go at 
a few of them.

> Glossary entries are actually given in as AARM notes next to the formal 
> definition 
 
I’m hoping that the glossary terms are more user-friendly than the sometimes 
convoluted words of the formal definition.

Attribute

A characteristic or property of an entity that can be queried, and in some 
cases specified. (First defined in 4.1.4).

 
Check
A test made during execution that some unusual condition has not occurred.
(These are mentioned all over the place, but the place to talk about them in 
general rather than specific checks looks to be 11 Exceptions).

 
Default Initial Condition
A condition that must hold true after the default initialization of an object. 
(Defined in 7.3.3 (2.a/5).

Logical Thread of Control
To paraphrase Wikipedia:
The smallest sequence of programmed instructions that can be scheduled 
independently.
(This is the successor to Task as the lowest level concurrent entity for most 
purposes, but Task wasn't defined in the Glossary either.
If we are going to define it, presumably it should go in 9 - 5.1 says see 9 
for a definition, but there isn't (yet) a definition there).

Master
The execution of a construct that includes the finalization of local objects 
(after completion but before leaving).
(Defined in 7.6.1).

Operational Aspect
An aspect that defines properties of an entity other than representation 
properties (see Representation Aspect).
(Defined in 13.1).

Parallel Construct
A parallel construct is a construct that introduces additional logical threads 
of control without creating a new task. Parallel loops and parallel block 
statements are examples of parallel constructs.
(Defined in 5.1).

Reduction Expression
A reduction expression maps or transforms a collection of values into a new 
set of values, and then summarizes the values produced by applying an 
operation to reduce the set to a single value result.
(Defined in 4.5.10).

Representation Aspect
An aspect that affects how an entity is mapped onto the underlying hardware, 
for example the size or alignment of an object.
(Defined in 13.1).

Subunit
A body that can be compiled separately from its embracing library unit.
(Defined in 10.1.3).
 
Suppress
To turn off a run-time check.
(Defined in 10.5).

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

From: Tucker Taft
Sent: Tuesday, May 7, 2019  4:02 PM

Enjoy! [Followed by version /01 of the AI - Editor.]

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

From: Randy Brukardt
Sent: Tuesday, May 7, 2019  4:18 PM

...
> We might want to verify that most of these terms also appear in the 
> index.
> At the moment, "logical thread of control" is not in the index.

It's not in the index because it is never defined in the Standard. It's used
a lot, but there is nothing resembling a definition in either Chapter 5 or 9.
So what would the index entry point to??

In general, it is helpful if one points out where each of these glossary items 
is defined (each entry appears in the AARM at that point, the actual glossary 
is a constructed entity).

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

From: Jeff Cousins
Sent: Wednesday, May 7, 2019  5:49 AM

This was my list of where terms are defined:

Attribute
A characteristic or property of an entity that can be queried, and in some 
cases specified.
(First defined in 4.1.4).

Check
A test made during execution that some unusual condition has not occurred.
(These are mentioned all over the place, but the place to talk about them 
in general rather than specific checks looks to be 11 Exceptions).

Default Initial Condition
A condition that must hold true after the default initialization of an object. 
(Defined in 7.3.3 (2.a/5).

Logical Thread of Control
To paraphrase Wikipedia:
The smallest sequence of programmed instructions that can be scheduled 
independently.
(This is the successor to Task as the lowest level concurrent entity for most 
purposes, but Task wasn't defined in the Glossary either.

If we are going to define it, presumably it should go in 9 - 5.1 says see 9 
for a definition, but there isn't (yet) a definition there).

Master
The execution of a construct that includes the finalization of local objects 
(after completion but before leaving).
(Defined in 7.6.1).

Operational Aspect
An aspect that defines properties of an entity other than representation 
properties (see Representation Aspect).
(Defined in 13.1).

Parallel Construct
A parallel construct is a construct that introduces additional logical threads 
of control without creating a new task. Parallel loops and parallel block 
statements are examples of parallel constructs.
(Defined in 5.1).

Reduction Expression
A reduction expression maps or transforms a collection of values into a new 
set of values, and then summarizes the values produced by applying an 
operation to reduce the set to a single value result.
(Defined in 4.5.10).

Representation Aspect
An aspect that affects how an entity is mapped onto the underlying hardware, 
for example the size or alignment of an object.
(Defined in 13.1).

Subunit
A body that can be compiled separately from its embracing library unit.
(Defined in 10.1.3).

Suppress
To turn off a run-time check.
(Defined in 10.5).

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

From: Tucker Taft
Sent: Wednesday, May 7, 2019  8:19 AM

> ...
>> We might want to verify that most of these terms also appear in the 
>> index.
>> At the moment, "logical thread of control" is not in the index.
> 
> It's not in the index because it is never defined in the Standard. 
> It's used a lot, but there is nothing resembling a definition in 
> either Chapter 5 or 9. So what would the index entry point to??

I think it can still be useful to index all *uses* of a term, even if it isn't 
felt necessary to have an Ada-specific definition of the term in the RM.

> In general, it is helpful if one points out where each of these 
> glossary items is defined (each entry appears in the AARM at that 
> point, the actual glossary is a constructed entity.

Sorry, I didn't know about that requirement.  I presume you figured that out.
If not, it looks like Jeff might have done the work.

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

From: Randy Brukardt
Sent: Wednesday, May 7, 2019  2:13 PM

> > It's not in the index because it is never defined in the Standard. 
> > It's used a lot, but there is nothing resembling a definition in 
> > either Chapter 5 or 9. So what would the index entry point to??
> 
> I think it can still be useful to index all *uses* of a term, even if 
> it isn't felt necessary to have an Ada-specific definition of the term 
> in the RM.

The index, in general, does not index uses of a term. There are a few special
cases where that is done (generally where the property is important to 
users/implementers, like "implementation-defined" or "inconsistent"). And even 
in those cases, there is an actual definition that is indexed first.

There is no definition of any sort (even informal) in the RM; this glossary 
entry is the first attempt at it. I suppose the glossary entry will get 
indexed (I think that happens automatically), so perhaps that is good enough 
(unless someone wants to take another swing at revising the intro to 
Chapter 9).

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

From: Randy Brukardt
Sent: Thursday, May 16, 2019  11:36 PM

We added a definition of "Container Aggregate" in this AI:

Container Aggregate
A construct used to define a value of a type that represents a collection of 
elements, by explicitly specifying the elements in the collection.

but there's no definition of Aggregate by itself. That's rather weird. I 
created one by borrowing the introduction to 4.3:

Aggregate
A construct used to define a value of a composite type that by specifying the 
values of the components of the type.

Neither this definition nor the one in 4.3 really tries to allow for container 
aggregates, but neither are outright wrong, either, so I'm not going to worry 
about that.

If any one has an objection (or improvement), please speak up (I've already 
made this change).

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

From: Gary Dismukes
Sent: Thursday, May 16, 2019  11:46 PM

I suggest deleting the word "that" from the definition of Aggregate. ;-)

Otherwise, both definitions seem OK.

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

From: Randy Brukardt
Sent: Friday, May 17, 2019  12:25 AM

Gotcha.

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

From: Brad Moore
Sent: Sunday, September 27, 2020  4:53 PM

[Part of his AARM review - Editor.]

7.6.1 Completion and Finalization
----------------------------------

In AARM 3.c.1/5, it is unclear what term is associated with the glossary entry.
We should be consistent with other entries, which start by mentioning the term.

3.c.1/5
"Glossary entry: {A master is the}[The] execution of a construct that 
includes waiting for tasks and finalization of objects associated with the 
master, prior to leaving the construct."

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

From: Randy Brukardt
Sent: Wednesday, November 4, 2020  11:08 PM

None of the new glossary entries were written in this form (see Annex N).
Perhaps they should have been, but I don't see much point in changing only one, 
and the reviewer of the Glossary (Tullio) didn't complain. The AARM note 
glossary entries don't have much value, and are just a left-over of the way
the Ada 95 tools were put together.

If you want to propose a replacement for AI12-0330-1, please do.

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

From: Brad Moore
Sent: Thursday, November 5, 2020  5:35 PM

Its not too important to me either, just that I think it might be confusing for
the reader, in general, to not mention the term that is being defined.

If others want to chime in that agree with my suggestion for the glossary 
entries, I'd be happy to work on a replacement for AI12-0330-1. If nobody feels 
this is necessary, I'm OK with withdrawing my comment. 

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

From: Tucker Taft
Sent: Thursday, November 5, 2020  6:24 PM

I would agree that it is confusing to have a glossary entry in the AARM 
without an obvious subject.

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

From: Jeff Cousins
Sent: Friday, November 6, 2020  3:01 AM

I am very keen that we should have more glossary entries and that they should 
be in a straightforward "An xyz is a ..." form. I find some of the definitions 
in the RM, such as nominal subtype, too oblique for my understanding.

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

From: Randy Brukardt
Sent: Friday, November 6, 2020  6:37 PM

>I am very keen that we should have more glossary entries and that they 
>should be in a straightforward "An xyz is a ..." form.

Ahem, most of the glossary entries in AI12-0330-1 were provided by some guy 
named Jeff Cousins (see !appendix, mail of May 7, 2019) and they're not in 
that form. Perhaps I should have noticed that they were not quite like the 
older entries, but I can't think of *everything*.

>I find some of the definitions in the RM, such as nominal subtype, too 
>oblique for my understanding.

Go right ahead and propose additional glossary entries. I don't think it hurts 
to have more of those (not sure how many people use the Glossary, but even if 
it is only a handful, it's probably worth improving).

Perhaps coordinate with Brad.

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

From: Jeff Cousins
Sent: Wednesday, November 11, 2020  2:27 PM

Mmm...

Mechanically making changes, the new definitions would be:

Aggregate
A{n aggregate is a} construct used to define a value of a composite type by 
specifying the values of the components of the type.
 
Attribute
A{n attribute is a} characteristic or property of an entity that can be 
queried, and in some cases specified.
 
Check
A{ check is a} test made during execution to determine whether a language rule 
has been violated.
 
Default Initial Condition
A{ default initial condition is a} property that holds for every 
default-initialized object of a given type.
 
Iterator Filter
A{n iterator filter is a} construct that is used to restrict the elements 
produced by an iteration to those for which a boolean condition evaluates to 
True.
 
Logical Thread of Control
A{ logical thread of control is a}n activity within the execution of a program 
that can proceed in parallel with other activities of the same task, or of 
separate tasks.
 
Master
{A master is t}[T]he execution of a construct that includes waiting for tasks 
and finalization of objects associated with the master, prior to leaving the 
construct.
 
Operational Aspect
A{n operational aspect is a}n aspect that indicates a logical property of an 
entity, such as the precondition of a subprogram, or the procedure used to 
write a given type of object to a stream.
 
Parallel Construct
A{ parallel construct is a}n executable construct that defines multiple 
activities of a single task that can proceed in parallel, via the execution 
of multiple logical threads of control.
 
Reduction Expression
A{ reduction expression is a}n expression that defines how to map or 
transform a collection of values into a new set of values, and then summarize 
the values by applying an operation to reduce the set to a single value.
 
Representation Aspect
A{ representation aspect is a}n aspect that indicates how an entity is mapped 
onto the underlying hardware, for example the size or alignment of an object.
 
Stable Property
A{ stable property is a} characteristic associated with objects of a given 
type that is preserved by many of the primitive operations of the type.
 
Subunit
A{ subunit is a} body that can be compiled separately from its enclosing 
program unit.
 
Suppress
To{ suppress is to} turn off a run-time check.
 

For nominal subtype,  I suppose something like:

“The nominal subtype of an object is the effective subtype after supplying 
any range constraints (for an unconstrained array subtype) or discriminants
(if not defaulted) at the time the object is declared.”

though I’ve tripped over the meaning of nominal subtype so many times, that’s 
why I’d like someone else to define it.

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

From: Tucker Taft
Sent: Wednesday, November 11, 2020  2:46 PM

>For nominal subtype,  I suppose something like:
>
>“The nominal subtype of an object is the effective subtype after supplying 
>any range constraints (for an unconstrained array subtype) or discriminants
>(if not defaulted) at the time the object is declared.”

Hmmm... That doesn't match my personal definition.

>though I’ve tripped over the meaning of nominal subtype so many times, that’s 
>why I’d like someone else to define it.

Let me try;

  The nominal subtype of a view of an object is the subtype specified when the 
  view is defined.

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

From: Jeff Cousins
Sent: Wednesday, November 11, 2020  3:26 PM

Thanks Tuck.

I was thinking, probably incorrectly, that in:

type Vector is array (Integer range <>) of Float;
Object : Vector (1 .. 3);

the nominal subtype of Object is:

array (Integer range 1 .. 3) of Float;

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

From: Tucker Taft
Sent: Saturday, November 14, 2020  8:06 AM

No, the nominal subtype is simply "Vector(1..3)".  I am curious what gave you 
the impression it was more complicated than that.

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

From: Jeff Cousins
Sent: Sunday, November 15, 2020  7:22 AM

Oh, it’s my misunderstanding, “nominal” can mean several things, such as all’s 
well for a rocket launch, but I when I hear the word it’s normally in a 
pejorative context where something is masquerading as something else.

What would you call the anonymous subtype

array (Integer range 1 .. 3) of Float;

in my example?

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

From: Tucker Taft
Sent: Sunday, November 15, 2020  7:40 AM

>Oh, it’s my misunderstanding, “nominal” can mean several things, such as all’s 
>well for a rocket launch, but I when I hear the word it’s normally in a 
>pejorative context where something is masquerading as something else.

Interesting.  We used the term in contrast with "actual" -- the nominal subtype 
is the subtype "named" in the declaration, whereas for a composite object, the
*actual* subtype might be something else (more constrained than the nominal 
subtype).  But you are right, in many contexts the term "nominal" means 
trivially small, or a potentially misleading use of some other term (e.g.
"The decision was nominally independent but ...").

>What would you call the anonymous subtype
>
>array (Integer range 1 .. 3) of Float;
>
>in my example?

Good question.  I suppose it would be "an anonymous array subtype that has the 
same component subtype and index constraint as the named array subtype."  I 
don't know of any use of such a notion in Ada.  You can convert from such an
anonymous subtype to the given named subtype, but there are many anonymous 
subtypes that are convertible to the given named subtype, because array 
conversion permits sliding as well as a change in the type of the index.  In 
any case, that anonymous subtype has no connection with the notion of 
"nominal" subtype.

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

From: Bob Duff
Sent: Sunday, November 15, 2020  9:42 AM

I think the "masquerading"/"misleading" meaning is correct. When you say

    X : String := "Hello";

it looks like the subtype of X is String, but that's fake news.
The subtype of X is *actually* String(1..5).

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

From: Randy Brukardt
Sent: Wednesday, November 11, 2020  5:17 PM

>Master
>{A master is t}[T]he execution of a construct that includes waiting for tasks 
>and finalization of objects associated with the master, prior to leaving the 
>construct.

This definition seems circular(as it mentions master in it) and is more 
confusing than helpful. When it starts talking about an execution, it makes
it seem like these are fully dynamic things that can occur anywhere, while 
in fact they are associated with particular syntactic constructs. So I view
them as a "thing" that gets entered and left related to the execution of 
particular constructs.

That's important since most of the uses (accessibility, finalization) describe 
a master as a thing, not an execution. It would be extremely confusing to 
refer to a master as a kind of verb.

Maybe something more like:

   A master is entered and left by the execution of particular constructs. 
   Each object and task is associated with a master. When a master is left,
   associated tasks are awaited and objects finalized.

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

From: Jean-Pierre Rosen
Sent: Wednesday, November 11, 2020  11:57 PM

Hmmm... This does not say what a master /is/. Maybe:

A master is an executable construct or entity. Each object and task is 
associated with a master. When a master is left, associated tasks are 
awaited and objects finalized.

("construct or entity" comes from 7.6.1(3/2))

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

From: Tullio Vardanega
Sent: Thursday, November 12, 2020  2:15 AM

This one def works for me.

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

From: Jeff Cousins
Sent: Thursday, November 12, 2020  12:17 PM

I’m happy for it to be reworded as it’s not obvious.  Personally I prefer 
JPR’s proposal to Randy’s as it is a straightforward “A master is ...” rather
than a description of what happens to a master.

For the record:

My original words were derived from Ada 2012 TC 1 7.6.1 (1), which says:

A master is the execution of a construct that includes finalization of local 
objects after it is complete (and after waiting for any local tasks ...)

which I think is where the confusion that Randy talks about begins.

My proposal of 2019/05/07 was:

Master
The execution of a construct that includes the finalization of local objects 
(after completion but before leaving).
 
Annex N of Ada 202x draft 26, presumably an edit of this, says:

Master.
The execution of a construct that includes waiting for tasks and finalization 
of objects associated with the master, prior to leaving the construct.

Randy’s proposal of 2020/11/11 says:

A master is entered and left by the execution of particular constructs. Each 
object and task is associated with a master. When a master is left, associated
tasks are awaited and objects finalized.

JPR then proposed:

A master is an executable construct or entity. Each object and task is
associated with a master. When a master is left, associated tasks are
awaited and objects finalized.

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

From: Randy Brukardt
Sent: Thursday, November 12, 2020  12:39 PM

One would hope that a glossary entry was clearer than the formal definition, 
not just a direct restating of it. If someone has trouble understanding the 
definition, they might turn to the glossary for help -- repeating the same 
words will not give any help.

J-P's definition is fine by me.

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

From: Tucker Taft
Sent: Thursday, November 12, 2020  1:03 PM

> One would hope that a glossary entry was clearer than the formal definition, 
> not just a direct restating of it. If someone has trouble understanding the 
> definition, they might turn to the glossary for help -- repeating the same 
> words will not give any help.

Perhaps, but saying something completely different doesn't really help either.
My sense is the glossary is mostly just capturing the definitions that are 
already in the RM, but in a central place.  I don't think we need to work too
hard to expand the definition, if the RM one is fairly clear.

> J-P's definition is fine by me.

Fine by me as well.

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

From: Randy Brukardt
Sent: Friday, November 20, 2020  9:47 PM

It would have helped if you had started with the actual text in AI12-0330-1 
rather than your original proposal. Some of these were changed quite a bit by
ARG discussion! In particular, the definition of Suppress is nothing like what
you have below [see Jeff's message of November 11th above in this 
summary - Editor]. And you're missing "container aggregate" completely. Grumble.
 
(Yes, I did update the AI and RM with these changes, as well as the others 
discussed.)
 
***************************************************************

From: Jeff Cousins
Sent: Monday, November 23, 2020  3:54 AM

Ok I missed out container aggregate and somehow didn’t use the latest 
definition of Suppress, but everything else should be taken from the latest
draft available online, not my original proposal.

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

From: Brad Moore
Sent: Tuesday, November 24, 2020  10:59 PM

I like the changes and the general approach that Jeff has proposed, after 
taking into account the items that Randy caught. It sounds like Randy has 
already incorporated these changes, which makes sense, since the proposed 
changes are pretty simple.

Does that mean there is no homework outstanding for this AI?

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

From: Randy Brukardt
Sent: Wednesday, November 25, 2020  10:34 PM

Correct. Of course, you're welcome to propose any other changes you might 
think are needed.

I found one needed change given another wording change that's in the hopper.
More on that once Steve gets back from vacation and can review it to ensure 
that it fixes his concern.

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

From: Bob Duff
Sent: Wednesday, December 9, 2020  11:01 AM

Suggested change to the wording for Suppress in AI12-0330-1.

    To suppress a check is to promise that it cannot fail,
    and to request that the compile optimize by disabling
    the check. The compiler is not required to honor this
    request.

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

From: Arnaud Charlet
Sent: Wednesday, December 9, 2020  11:06 AM

>     To suppress a check is to promise that it cannot fail,
>     and to request that the compile optimize by disabling

                              compiler

>     the check. The compiler is not required to honor this
>     request.

Note that one common case causing wrong expectations with customers is when 
the compiler can statically determine that a runtime check will fail.
In this case, a systematic raise is inserted instead of a runtime check and 
this systematic raise is *not* suppressed by GNAT, even when specifying pragma
Suppress.

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

From: Edmond Schonberg
Sent: Wednesday, December 9, 2020  11:14 AM

>>    To suppress a check is to promise that it cannot fail,

I would say “assert” rather than “promise”.

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

From: Richard Wai
Sent: Wednesday, December 9, 2020  11:14 AM

I don't really see the purpose of calling it a "request". I really is a
permission given by the user to the compiler, and the user aught to see it
that way. I feel like "request" is too strong, it suggests some responsibility
for the compiler to "try", but in fact the RM does not make any such 
requirement on the compiler. I think "request" is therefore misleading. And it 
seems the last sentence is there exactly to make that clear. The Suppress
pragma is really an optimization hint, and in all other languages, those are
weak suggestions and everyone recognizes that, and I think we should give a
similar impression to the user.

Using the word "permission" suggest that it is the compiler's decision (which
it is). 

I'd think "To suppress a check is to promise that it cannot fail, and to give 
permission to the compiler to omit check." is more concise, and is closer to 
what it actually means to "Suppress" a check.

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

From: Bob Duff
Sent: Wednesday, December 9, 2020   1:09 PM

> I don't really see the purpose of calling it a "request". I really is 
> a permission given by the user to the compiler, and the user aught to 
> see it that way. I feel like "request" is too strong, it suggests some 
> responsibility for the compiler to "try", but in fact the RM does not 
> make any such requirement on the compiler.

I don't agree. It's not a matter of "try" -- the compiler is using a 
deterministic algorithm.

The compiler should honor the request unless there's a good reason not to, so 
"request" is neither too weak nor too strong. The whole point of suppression 
is efficiency.
As 11.5 says:

                            Implementation Advice

28  The implementation should minimize the code executed for checks that have 
    been suppressed.
...
28.a        Implementation Note: However, if a given check comes for free (for
            example, the hardware automatically performs the check in parallel
            with doing useful work) or nearly free (for example, the check is
            a tiny portion of an expensive run-time system call), the
            implementation should not bother to suppress the check. Similarly,
            if the implementation detects the failure at compile time and
            provides a warning message, there is no need to actually suppress
            the check.

The last sentence above is the case Arno mentioned, except a warning is not 
always appropriate.

As I said during the meeting, if the compiler is generating extra instructions
to perform a check, and it fails to remove those instructions when the check
is suppressed, and that causes significant inefficiency, then that's a
compiler bug.  (And note that unlike Robert Dewar, I do not consider "compiler
bug" to be synonymous with "nonconformance".)  As a user I would report such a
bug, and as a compiler writer I would fix it.

The word "permission" is too weak -- it implies that a compiler that ignores
Suppress is just as good as one that implements it properly.

But none of this is important -- it's just the glossary -- so I'll shut up 
now.  ;-)

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

From: Bob Duff
Sent: Wednesday, December 9, 2020  1:15 PM

> I would say “assert” rather than “promise”.

Yes, that's better.

Should we also say something like "It is wrong to suppress checks that can
fail" or "Suppressing checks that can fail can cause programs to malfunction
in arbitrary ways"?
Lots of people don't understand that (e.g. they expect to get wraparound
semantics when suppressing overflow checks).

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

From: Edmond Schonberg
Sent: Wednesday, December 9, 2020   1:28 PM

> Should we also say something like "It is wrong to suppress checks that 
> can fail" or "Suppressing checks that can fail can cause programs to 
> malfunction in arbitrary ways”?

Yes to the second formulation (in other words, if you suppress a check that 
would fail, all bets are off).  I’d rather avoid “promise” and “wrong” because
they have a moral ring that doesn’t belong. I don’t know if saying “the 
behavior of the program is undefined” would be helpful.

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

From: Bob Duff
Sent: Wednesday, December 9, 2020  2:07 PM

Taking into account some suggestions:

    To suppress a check is to assert that it cannot fail, and to request
    that the compile optimize by disabling the check. The compiler is
    not required to honor this request. Suppressing checks that can fail
    can cause programs to behave in arbitrary ways.

> I don’t know if saying “the behavior of the program is undefined”
> would be helpful.

Well, given the number of people who misunderstand what "undefined behavior"
means in the C standard, I'd rather not. I changed "malfunction" to "behave"
above, because the worst thing is when it works just fine -- until you make 
an unrelated change a year later. I've seen people say, "I think this C code 
has undefined behavior. So why didn't I get a SIGSEGV?"

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

From: Tucker Taft
Sent: Wednesday, December 9, 2020  2:34 PM

> Taking into account some suggestions:
> 
>    To suppress a check is to assert that it cannot fail, and to request
>    that the compile optimize by disabling the check. The compiler is
         "compiler" 
>    not required to honor this request. Suppressing checks that can fail
>    can cause programs to behave in arbitrary ways.

Looks good.

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

From: Steve Baird
Sent: Wednesday, December 9, 2020  5:03 PM

Agreed.

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

From: Randy Brukardt
Sent: Thursday, December 10, 2020  2:51 PM

>Taking into account some suggestions:
>
>    To suppress a check is to assert that it cannot fail, and to request
>    that the compile optimize by disabling the check. The compiler is
>    not required to honor this request. Suppressing checks that can fail
>    can cause programs to behave in arbitrary ways.

One minor comment. I had a brief moment of confusion when encountering "it" 
in the above (what cannot fail?), and writing out "the check" only adds 6 
characters (and we're not paying by the character!) and eliminates any such
confusion. Moreover, we repeat "the check" later, so it's not like we're 
avoiding redundancy. So I used:

   To suppress a check is to assert that the check cannot fail, and to request
    that the compiler optimize by disabling the check. The compiler is
    not required to honor this request. Suppressing checks that can fail
    can cause programs to behave in arbitrary ways.

I rekeyed this since I'm working at home, and never noticed the other typo -- 
of course, I didn't copy it, either, since I read what it was supposed to say 
and not what it actually says.

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

From: Tucker Taft
Sent: Thursday, December 10, 2020  10:42 AM

Here is a first draft [of the glossary entry for Accessibility level - 
Editor].  Comments welcome.

Accessibility Level : An accessibility level is a representation of the 
lifetime of an entity in terms of the level of dynamic nesting within which
the entity is known to exist.  Formally it is defined in terms of the set of
masters in which it is nested.  Given a value of a given access type that 
designates some object, the dynamic accessibility checks ensure that the 
accessibility level of the designated object is no deeper than that of the 
access type, to prevent a reference to an object that has gone out of scope.
Based on the static nesting of the master constructs associated with the 
relevant masters, there are corresponding legality rules that require that the
accessibility level of the designated object not be statically deeper than
that of the access type.

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

From: Gary Dismukes
Sent: Thursday, December 10, 2020  12:57 PM

> Here is a first draft.  Comments welcome.

It reads well, though is a bit lengthy for a glossary entry.  This would now
be the longest entry, after the one for primitive operations (which is also
rather lengthy), but maybe that's OK.  It does seems like the second sentence
could be left out ("Formally it is defined..."), especially since these are
supposed to be "informal" definitions. ;-)

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

From: Tucker Taft
Sent: Thursday, December 10, 2020  1:47 PM

Here is an attempt to "dumb it down" a bit ... ;-)

-------

Accessibility Level : An accessibility level is a representation of the 
lifetime of an entity in terms of the level of dynamic nesting within which
the entity is known to exist. Given an access value that designates some
object, the dynamic accessibility checks ensure that the accessibility level
of the designated object is no deeper than that of the type of the access
value, to prevent a dangling reference.  Based on static nesting, there are
corresponding legality rules that require that the accessibility level of the
designated object not be statically deeper than that of the access type.

---

Any better?

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

From: Gary Dismukes
Sent: Thursday, December 10, 2020  1:57 PM

Yes, that looks pretty good.  One minor change I suggest is removing the word 
"the" from "the dynamic accessibility checks".

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

From: Tucker Taft
Sent: Thursday, December 10, 2020  2:32 PM

Works for me!

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

From: Ed Schonberg
Sent: Thursday, December 10, 2020  3:20 PM

Looks good, but I would move “ prevent a dangling reference” earlier in the
second sentence so that the purpose of the construct is more immediately
stated.

   The dynamic accessibility checks prevent a dangling reference by ensuring
   that the accessibility level ….

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

From: Randy Brukardt
Sent: Thursday, December 10, 2020  3:35 PM

Yea verily!

I was going to complain that your original version had messed up the 
relationship between master and master construct. Since that area is plenty 
confusing to experts, I don't want anything "official" that is incorrect, even
if not normative. (Especially as we have carefully crafted Glossary entries
for the terms, don't want to contradict or even repeat those.)

But I see you got rid of all of that, so I didn't have to write the above. ;-)

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

From: Erhard Ploedereder
Sent: Thursday, December 10, 2020  8:25 PM

> Here is a first draft.  Comments welcome.
> -Tuck
 
>Accessibility Level : An accessibility level is a representation of the 
>lifetime of an entity in terms of the level of dynamic nesting within which
>the entity is known to exist.  Formally it is defined in terms of the set of
>masters in which it is nested.

who or what is the nested "it"? acc.level, lifetime, entity. Be more specific.

>Given a value of a given access type that designates some object, the dynamic
>accessibility checks ensure that the accessibility level of the designated
>object is no deeper than that of the access type, to prevent a reference to
>an object that has gone out of scope.

"has gone out of scope" -> "no longer exists" or "whose lifetime has ended". 
An object can be out of scope, and yet exist and be referenceable. Think e.g.
about propagated local exceptions or about private data.

>Based on the static nesting of the master constructs associated with the 
>relevant masters, there are corresponding legality rules that require that
>the accessibility level of the designated object not be statically deeper 
>than that of the access type.

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

From: Erhard Ploedereder
Sent: Thursday, December 10, 2020  8:30 PM

>Accessibility Level : An accessibility level is a representation of the 
>lifetime of an entity in terms of the level of dynamic nesting within which
>the entity is known to exist. Given an access value that designates some
>object, the dynamic accessibility checks ensure that the accessibility level
>of the designated object is no deeper than that of the type of the access
>value, to prevent a dangling reference.  Based on static nesting, there are
>corresponding legality rules that require that the accessibility level of the
>designated object not be statically deeper than that of the access type.

Looks good/better to me too.

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

From: Jean-Pierre Rosen
Sent: Friday, December 11, 2020  1:52 AM

> The first sentence:
> 
>   An accessibility level is a representation of the lifetime of an entity in
>   terms of the level of dynamic nesting within which the entity is known to
>   exist.
> 
> is the most important.  I would welcome rephrasings of this which you would
> find more enlightening.

Maybe simply:
Accessibility Level : An accessibility level is the level of dynamic nesting 
within which the entity is known to exist.

I find "representation of the lifetime" confusing. How do you represent a 
lifetime?

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

From: Randy Brukardt
Sent: Friday, December 11, 2020  3:19 AM

>I find "representation of the lifetime" confusing. How do you represent
>a lifetime?

Depends on the context. I would have answered "62" without any. :-) I don't 
see any problem with representing a lifetime so long as the context is clear.
One does it all the time, the representation of my lifetime is 62 years, since
it implies a duration ("time", you know). In this case, it's talking about how
long an object exists, that is, the duration of it's "life", or "lifetime" for
short. I would have preferred this concept was called "lifetime" in the first
place, and I think it is quite important to get that into the discourse (I
always have to think about lifetimes to understand accessibility, even now
after 25+ years).

If I had a quibble with this wording, is that it is rather focused on the 
motivating case (dangling objects), while there are many other uses within Ada
and a few that are ultimately more important (particularly, the dangling
tagged type checks of class-wide returns). So making the wording a bit more
abstract and then giving access types as an example would probably be better.
(By this, I mean that I'd try to define "deeper" and "statically deeper"
checks without giving a specific use, and then give an example. I'm not going
to try a rewording minutes before bed, though.)

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

From: Randy Brukardt
Sent: Friday, December 11, 2020  6:13 PM

Now that it's daytime :-), here's the sort of thing I was thinking about:

Accessibility Level : An accessibility level is a representation of the
lifetime of an entity in terms of the level of dynamic nesting within which
the entity is known to exist. Dynamic accessibility checks ensure that an
entity does not outlive the lifetime of some related entity, by checking that
the level of the first entity is no deeper than the second entity. Based on
static nesting, there are corresponding legality rules that the level of the
first entity is not statically deeper than the second entity. For instance,
given an access value that designated some object, accessibility checks
prevent a dangling reference by ensuring that the object outlives the access
type.

The problem (not very strong, admittedly) I had with the previous wording is
that it talks like the only reason for these checks is access types, and that
is far from the reality. The fact that the checks pair for all uses, and that
there are many uses, seems lost in Tucker's proposed glossary entry.

If I had been defining this in the first place, I would have called these
"lifetime checks" and "outlive" would have been a technical term. For most
people, "accessibility" is just as meaningful as "muggywump" or Steve's
"frobisher" (noise words used as the placeholder for a term when discussing
possible rules). I always have to translate things into lifetime in order to
even understand them at all; the above is the way I think of these rules.

[Tucker has told me a zillion times why they didn't do that, I realize they
had reasons, they just aren't very compelling. :-)]

I can imagine why the above might be too much for some, as it rather diverges
from the orthodoxy. Perhaps there is an intersection that would be better than
either.

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

From: Tucker Taft
Sent: Tuesday, December 15, 2020  4:34 PM

Yours seems to be getting pretty abstract.  I also think the sense of the
check is now backwards, as a result of your switching to "outlive".  Let me
see if I can hit that intermediate point you mention, and make sure it says
the correct thing:

Accessibility Level : An accessibility level is a representation of the
lifetime of an entity in terms of the level of dynamic nesting within which
the entity is known to exist. Dynamic accessibility checks ensure that a
reference does not outlive the entity to which it refers, by checking that the
level of the entity is no deeper than the level of the reference.
Based on static nesting, there are corresponding legality rules that the level
of the entity is not statically deeper than that of the reference.

------

I have used the rather generic term "reference" which I think handles pretty 
much any sort of "relation" we worry about.

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

From: Tullio Vardanega
Sent: Wednesday, December 15, 2020  8:37 AM

I believe this works.

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

From: Randy Brukardt
Sent: Wednesday, December 15, 2020  9:56 PM

This is roughly what I had in mind, only better. Thanks.

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

From an informal RM review from John Barnes (March 8, 2021)

N(2.1/5)     accessibility level third line has referce should be reference

[Editor's note: There is a whopper here, too. The following is always true:

...by checking that the level of the reference is no deeper than the level of the reference.

The first "reference" here should be "entity".]

N(38.2/5)   suppress   add “a” thus  ...  can cause a program to behave ...

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

Questions? Ask the ACAA Technical Agent