!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) @drepl The execution of an Ada program consists of the execution of one or more @i. Each task represents a separate thread of control that proceeds independently and concurrently between the points where it @i with other tasks. The various forms of task interaction are described in this clause, and include: @dby The execution of an Ada program consists of the execution of one or more @i. Each task represents a separable activity that proceeds independently and concurrently between the points where it @i with other tasks. A single task, when within the context of a parallel construct, can represent multiple @i 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 ... ***************************************************************