CVS difference for ai12s/ai12-0443-1.txt
--- ai12s/ai12-0443-1.txt 2022/06/14 23:39:33 1.3
+++ ai12s/ai12-0443-1.txt 2022/06/21 03:14:39 1.4
@@ -421,5 +421,266 @@
!appendix
+From: Randy Brukardt
+Sent: Friday, June 10, 2022 1:03 AM
+
+I've finished added the new Terms and Definitions to the RM, and following are
+some fixes to that AI. There were also a few typos in the AI (stray brackets,
+leftover Editor's notes) that I didn't keep track of.
+
+Please tell me if you disagree with any of these or would like any changes.
+I'm hoping to "freeze" this work on Monday (I don't think I'll finish it
+tomorrow, but it's possible), so I need comments ASAP.
+
+---
+
+We have:
+
+ * declaration. A declaration is a language construct that associates a
+ name with (a view of) an entity. A declaration may appear explicitly
+ in the program text (an explicit declaration), or may be supposed to
+ occur at a given place in the text as a consequence of the semantics
+ of another construct (an implicit declaration).
+
+This is the glossary style, not rewritten into appropriate Term style. (The
+repeat of the term and the punctuation at the end is a giveaway.) We're also
+misusing "may" here (there's no permission, it's about possibility.) I
+replaced this with:
+
+ * declaration. a language construct that associates a name with (a
+ view of) an entity
+ * Note 1 on entry: A declaration can appear explicitly in the
+ program text (an explicit declaration), or can be supposed to
+ occur at a given place in the text as a consequence of the
+ semantics of another construct (an implicit declaration).
+
+-----
+
+We have both "private type" and "incomplete type" with the exact same
+definition:
+
+ a view of a type that reveals only some of its properties
+
+While technically true, it is likely to be confusing to someone. So I changed
+the definition of incomplete types slightly:
+
+ a view of a type that reveals only a few of its properties
+
+Hopefully, it is obvious that "a few" < "some". :-)
+
+-----
+
+AI12-0443-1 does not include the term "compilation unit", even though it
+appeared in the glossary and is used in other definitions. That may have been
+because a direct translation of the glossary entry doesn't work as a
+definition.
+
+It seems important to have this term for completeness, so I took a cue from
+the definition of "program unit" and added it as follows:
+
+ * compilation unit. a program unit that is separately compiled
+ * Note 1 on entry: A compilation_unit contains either
+ the declaration, the body, or a renaming of a program unit.
+
+-----
+
+In AI12-0443-1, we have a subclause heading:
+
+ . Run-time Actions
+
+But we generally (but not always) write this as "Runtime", especially when
+it is used as a modifier, as it is here. (For some reason, we have "runtime
+check" and "run-time effect". Yuck.) So I've changed this to:
+
+ . Runtime Actions
+
+-----
+
+In AI12-0443-1, we have a new definition:
+
+ * needed compilation unit. a compilation unit that is needed to
+ produce an executable partition, because some entity declared or
+ defined within the unit is used elsewhere in the partition
+
+But we shouldn't use part of a term to define the term if at all possible.
+So I replaced "needed" by "necessary" in the definition:
+
+ * needed compilation unit. a compilation unit that is necessary to
+ produce an executable partition, because some entity declared or
+ defined within the unit is used elsewhere in the partition
+
+----
+
+In AI12-0443-1, we are missing a definition for "assertion", a term that is
+used in the definition of a number of other terms, and one that was defined
+in the Glossary.
+
+The Glossary definition is not very useful, and enumerates the kinds of
+assertions (and leaves out the new Ada 2022 assertions). The part of it that
+would become a note is a better definition, so I swapped and generalized
+them:
+
+So I replaced the entire thing with:
+
+ * assertion. a boolean expression that is expected to be True when evaluated
+ at certain specified places
+ * Note 1 on entry: Certain pragmas and aspects define various kinds
+ of assertions.
+
+I put this into the "runtime actions" group, as it seemed like the best fit
+(in doing so, I slightly changed the wording from "at runtime" to "when
+evaluated" to better fit the grouping).
+
+-----
+
+There are other terms that seem missing in AI12-0443-1. Most of these are
+mentioned in notes, some even as a sort of definition (which definitely should
+not be in a note for some other term). I mention them for completeness and
+possible future work, rather than to do anything now:
+
+* allocator
+* subsystem
+* nonlimited type
+* derivation class
+* full view of a type
+* child unit
+* operative constituent
+* instantiation
+
+We don't have much about visibility here, either. Terms like "denotes",
+"static denotes", "statically names", "homograph", "overloaded" and so on are
+not here (or in the old glossary).
+
+It also would make sense to define "erroneous execution" and "bounded error",
+since they are so commonly used.
+
+[Note: It would not be a big deal to add some or all of these now, BUT I would
+need proposed wording by Monday. If someone feels a strong urge, feel free to
+try. I note that Tucker did add a few terms, mostly in the exception handling
+section, so it certainly is OK to do so.]
+
+----
+
+I propose adding the following AARM note to RM 1.3 to better explain the
+differences between the definitions found in 1.3 and those found in the body
+of the RM. (Since this is an AARM note, it has nothing to do with the ISO
+version.)
+
+AARM Discussion: The definitions found here are short, descriptive definitions.
+These are most useful for comprehension when an exact meaning is not needed.
+More formal, detailed definitions are found in the body of the RM; these are
+needed to determine the exact application of rules to constructs and entities.
+
+To see the difference, consider "aliased view". The descriptive definition is
+"a view of an object that can be designated by an access value". The formal
+definition is a lengthy paragraph in 3.10 that defines 10 separate constructs
+as aliased views. In order to reason about a language rule that requires an
+aliased view in a particular context, one needs to look at the list of
+constructs in order to determine if the object in hand is actually an
+aliased view. The descriptive definition is no help in this case.
+End AARM Discussion.
+
+****
+
+I would have used "variable" as the example, but I did not as we don't have it
+in the list of terms; and given the intent not to define "common terms, which
+a qualified user of the document will already know", it probably should not be
+there.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, June 10, 2022 6:36 AM
+
+All of your suggestions make sense to me. Thanks for doing all this work...
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Friday, June 10, 2022 12:38 PM
+
+> In AI12-0443-1, we have a subclause heading:
+>
+> . Run-time Actions
+>
+> But we generally (but not always) write this as "Runtime", especially
+> when it is used as a modifier, as it is here. (For some reason, we
+> have "runtime check" and "run-time effect". Yuck.) So I've changed this to:
+>
+> . Runtime Actions
+
+The RM is definitely still inconsistent here, but when I search the Ada 2022
+RM I only get 9 instances of the unhyphenated form "runtime", but 69 instances
+of the hyphenated form "run-time" (with the hyphen). (There are also 31 cases
+of "run time", which are hopefully all cases where we're referring to the time
+at which something is run, but I didn't check them.) So I'm not sure why you
+say that we generally use the form "runtime".
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June 13, 2022 3:13 PM
+
+Humm. I see a lot more "runtime"s than that (I counted 15 now, and there are
+more in the index and generated annexes, which I probably counted the other
+day). And I see some "run-time"s, roughly the same number, but I did not count
+the generated header "Bounded (Run-Time) Errors". So to me it appeared to be
+a wash (without making a formal count).
+
+But I recall a discussion a few years ago where we researched and determined
+that "runtime" is preferred in new text. So that's what I've been using. I'd
+replace them all, but that seems like unnecessary churn.
+
+I would consider changing the generated header (I'm changing other generated
+headers today anyway), but it's probably a bit late this time to do that-
+probably ought to let everyone weigh in.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Monday, June 13, 2022 3:32 AM
+
+I thought Tuck had a distinction between "xyz happens at runtime" and "the
+runtime" (system), not that I remember which had a hyphen and which didn't.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June 13, 2022 8:59 PM
+
+>I thought Tuck had a distinction between "xyz happens at runtime" and
+>"the runtime" (system), not that I remember which had a hyphen and
+>which didn't.
+
+There is a distinction, but neither has a hyphen. "run time" is an actual
+time, and is written with two words (and a space). Made-up words don't have
+hyphens (as in our regular rules), and thus the modifier "runtime" (which is
+mainly an identifier, and not referring to a specific time) does not have a
+hyphen.
+
+But, on top of that, we also have on-line references that suggest that
+"runtime" is now preferred for all uses. I personally like that, since I've
+used the spelling "runtime" pretty much from the beginning of my career (a
+look at the AI !appendixes shows that clearly :-).
+
+I tried to find the reference to that discussion, but I can't find it in large
+part because so many of us write "runtime" as a matter of course.
+There's a *lot* of "runtime"s in the AI12's and the associated mail. (It's
+also possible that the thread was not recorded anywhere.)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 10, 2022 1:03 AM
+
****************************************************************
+From: Randy Brukardt
+Sent: Friday, June 10, 2022 1:03 AM
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 10, 2022 1:03 AM
+
+****************************************************************
Questions? Ask the ACAA Technical Agent