CVS difference for ai12s/ai12-0075-1.txt

Differences between 1.7 and version 1.8
Log of other versions for file ai12s/ai12-0075-1.txt

--- ai12s/ai12-0075-1.txt	2018/01/18 07:16:33	1.7
+++ ai12s/ai12-0075-1.txt	2018/01/18 08:43:00	1.8
@@ -1,4 +1,4 @@
-!standard 4.9(6)                                  18-01-05    AI12-0075-1/05
+!standard 4.9(6)                                  18-01-17    AI12-0075-1/06
 !standard 4.9(18)
 !class Amendment 13-06-09
 !status work item 13-06-09
@@ -22,12 +22,11 @@
 
 !wording
 
-Add to the definition of static function (i.e. insert as the penultimate
-item of the 4.9 (19-22) list):
+Add after 4.9(21): [Adding to the definition of "static function"]
 
-  - a static expression function (see 6.8)
+  - a static expression function (see 6.8);
 
-Add at the and of the 4.9 "Legality Rules" section:
+Add after AARM 4.9(37.e/2):
 
   AARM Discussion:
   The preceding "statically unevaluated" rule allows
@@ -39,9 +38,10 @@
   because evaluation of a function call includes evaluation of
   all of its actual parameters.
 
-Introduce a "Static Semantics" section for 6.8 immediately before the
-"Legality Rules" section, containing:
+Add after 6.8(3/4):
 
+  Static Semantics
+
   A "potentially static expression" is defined in the same way as a
   static expression except that
      - a name denoting a formal parameter of an expression function
@@ -80,7 +80,7 @@
   progenitor type is a static expression function.
   [A static expression function is a static function; see 4.9].
 
-In 7.3.2, add the following at the end of the Static semantics section.
+Add after 7.3.2(8.2/5) [as added by AI12-0199-1]
 
 If one or more invariant expressions apply to a nonabstract type T, then
 a subprogram or entry is said to be "type invariant enforcing" for T if
@@ -110,12 +110,15 @@
      Each such part of type T is said to be "subject to an invariant check"
      for T.
 
-In the Dynamic Semantics section, replace 7.3.2(15/4-20/5) with
+Replace 7.3.2(15/4-20/5) with: [as modified by AI12-0193-1]
 
    An invariant check is checked upon successful return from a call on any
    subprogram or entry which is type invariant enforcing for T. The check is
    performed on each part of type T which is subject to an invariant check
-   for T.
+   for T. In the case of a call to a protected operation, the check is
+   performed before the end of the protected action. In the case of a call
+   to a task entry, the check is performed before the end of the rendezvous.
+
 
 !discussion
 
@@ -126,7 +129,8 @@
 expression function. And, of course, the term itself is subject to
 discussion - we might choose a different term.
 
-This version incorporates feedback from the last two meetings so that
+This version incorporates feedback from the Vienna and Lexington meetings
+(#57 & 58) so that
    a) in order for an expression function to be a static function, you
       have to explicitly ask for it by specifying the Static aspect
       (a new Boolean aspect).
@@ -1022,5 +1026,263 @@
 Good catch! I agree that we don't want to delete that sentence.
 The changes 7.3.2 are intended to introduce the definition of a new term and
 otherwise be semantics-preserving.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 18, 2018  1:03 AM
+
+> > You've lost the words added by AI12-0193 (i.e. "In the case of a
+> > call to a protected operation, the check is performed before the end
+> > of the protected action. In the case of a call to a task entry, the
+> > check is performed before the end of the rendezvous."
+>
+> Good catch! I agree that we don't want to delete that sentence.
+> The changes 7.3.2 are intended to introduce the definition of a new
+> term and otherwise be semantics-preserving.
+
+True, but not critical; your editor is used to merging wording from AIs that
+change the same paragraph. There'd only be a problem if the AI specifically
+mentioned the old AI (193 in this case) and THEN left out the words.
+Otherwise, it's just two insertions into the same paragraph.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 18, 2018  1:41 AM
+
+> Another iteration of this AI.
+
+Here are my editorial comments on this AI:
+
+> Add to the definition of static function (i.e. insert as the
+> penultimate item of the 4.9 (19-22) list):
+
+We don't describe changes this way; we always use the paragraph number in the
+RM. You can put a comment in square brackets after the actual change, thus:
+
+Add after 4.9(21): [Adding to the definition of "static function"]
+
+>   - a static expression function (see 6.8)
+
+This needs to end with a semicolon to look like the other bullets in this group.
+
+> Add at the and of the 4.9 "Legality Rules" section:
+
+Same here, this should be:
+
+Add after AARM 4.9(37.e/2):
+
+> Introduce a "Static Semantics" section for 6.8 immediately before the
+> "Legality Rules" section, containing:
+
+Yet again. The header "Static Semantics" should just be part of the new
+wording. Thus:
+
+>In 7.3.2, add the following at the end of the Static semantics section.
+
+Broken record time. This should say:
+
+Add after 7.3.2(8.2/5): [Static semantics wording added by AI12-0199-1.]
+
+>In the Dynamic Semantics section, replace 7.3.2(15/4-20/5) with:
+
+The first part isn't needed.
+
+I added the two sentences from AI12-0193-1 to this new paragraph (at the end).
+
+In the discussion:
+> This version incorporates feedback from the last two meetings so that
+
+No one reading this in the distant future will have any idea of what two
+meetings you are talking about. That matters if they want to look up the
+associated minutes. It should say something like "Vienna and Lexington meetings"
+possibly with the meeting numbers as well (since it appears that there will
+be another Lexington meeting).
+
+I've made these changes and posted the result as version /06.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 18, 2018  2:37 AM
+
+> Another iteration of this AI.
+
+Here are my substantive comments for discussion (the editorial comments were
+sent in a previous message).
+
+>Add after 6.8(3/4):
+>
+>  Static Semantics
+
+This gives this relatively small subclause two Static Semantics sections.
+While that isn't prohibited, we do try to avoid having multiple occurrences of
+the same section. Assuming this cannot be after 6.8(6/4), probably it would be
+best to move 6.8(6/4) after this wording so that there is one such section.
+
+----
+
+>  A "potentially static expression function" is defined to be an expression function
+>    - whose expression is a potentially static expression; and
+>    - which contains no calls to itself; and
+>    - each of whose parameters (if any) is of mode IN and is of a
+>      static subtype; and
+>    - whose result subtype is a static subtype; and
+>    - to which no precondition or postcondition expression applies; and
+>    - which is not type invariant enforcing for any type (see 7.3.2); and
+>    - which is not a completion.
+
+"Static subtype" includes "static string subtypes". Are we intending to allow
+expression functions to be static for string-valued expressions? We don't allow
+that for attributes, so that would seem to be an expansion. (I don't feel
+strongly either way, it just seems like something that should be done
+consciously, not be accident.)
+
+----
+
+>  The following language-defined representation aspect may be specified
+> for a potentially static expression function.
+>
+>    Static - The type of aspect Static is Boolean.
+>
+>  A "static expression function" is defined to be an expression
+> function  whose Static aspect is True.
+>  In addition, an inherited function is defined to be a static
+> expression  function if the corresponding primitive function of the
+> parent or  progenitor type is a static expression function.
+>  [A static expression function is a static function; see 4.9].
+
+The definition of this aspect seems too minimal. There ought to be some
+description of what it is for, what the value is if not specified, and usually
+some discussion of inheritance. See the wording for No_Return for a model. (I
+note that you left out the part about the value of the aspect being required to
+be static; I don't think we want to be determining staticness at runtime. :-)
+
+I also think that we have to be careful about defining this (or any other)
+aspect too narrowly. As such, I think it would be better to define this for all
+expression functions (or maybe even all functions), and then use Legality Rules
+to prevent setting it to True anywhere except where it is meaningful. That will
+help if we ever want to expand the definition of staticness to include
+completions or other kinds of types.
+
+Aside: Should this be possible for a generic function or instance thereof? An
+expression function can complete a generic function. Humm, I suppose the "no
+completions" takes care of that, too.
+
+Anyway, I suggest something more like:
+
+   The following language-defined representation aspect may be specified
+   for an expression function.
+
+     Static   The type of aspect Static is Boolean. When aspect Static is True
+	      for an expression function, the function is a *static expression
+	      function*. If directly specified, the aspect_definition shall be a
+	      static expression.
+
+              <Some inheritance rule here>; otherwise, if not directly
+	      specified, the aspect is False.
+
+   Redundant[A static expression function is a static function; see 4.9.]
+
+I have <Some inheritance rule here> because the one you have isn't right. It
+says:
+
+>  In addition, an inherited function is defined to be a static
+> expression function if the corresponding primitive function of the
+> parent or progenitor type is a static expression function.
+
+Channeling what you did to me when working on the Nonblocking aspect, what does
+this mean if there are multiple corresponding subprograms?? (That is, inherited
+from multiple progenitors (or a parent)).
+
+As it stands, no progenitor primitive could be an expression function (there is
+a use for that, but we've never wanted do the work), so one solution would be to
+talk only about the parent. But if we start allowing completions or expression
+functions in progenitors, such a rule would fall over, so assuming that
+introduces a (Standard) maintenance hazard.
+
+Maybe it would be better to say "if {some}[the] corresponding primitive
+function". In any case, this ought to be reworded in terms of inheritance of the
+aspect.
+
+I also wonder if we actually need the term "static expression function".
+Can't we just say "an expression function with the Static aspect True" in the
+handful of places where we need the term? (That's especially true as
+"potentially static expression function" could be confused with "static
+expression function".)
+
+Anyway, with the proposed rewording, we need a Legality Rule:
+
+Aspect Static shall only be specified to have the value True if the associated
+expression function is a potentially static expression function.
+
+If we reordered this clause as I suggested, that would naturally go after
+6.8(5/4).
+
+----
+
+>If one or more invariant expressions apply to a nonabstract type T,
+>then a subprogram or entry is said to be "type invariant enforcing" for T if
+>   - it is the Read or Input stream-oriented attribute of the type T; or
+>   - it is declared within the immediate scope of T (or by an instance of a
+>     generic unit, and the generic is declared within the immediate scope of
+>     type T), and either:
+>
+>       * has a result with a part of type T; or
+>       * has one or more *out* or *in out* parameters with a part of type T; or
+>       * has an access-to-object parameter or result whose designated type has
+>         a part of type T; or
+>       * is a procedure or entry that has an *in* parameter with a part of type
+>         T.
+>
+>   - and either:
+>
+>       * T is a private type or a private extension and the subprogram or
+>         entry is visible outside the immediate scope of type T or overrides
+>         an inherited operation that is visible outside the immediate scope
+>         of T; or
+>       * T is a record extension, and the subprogram or entry is a primitive
+>         operation visible outside the immediate scope of type T or overrides
+>         an inherited operation that is visible outside the immediate scope
+>         of T.
+>
+>     Each such part of type T is said to be "subject to an invariant check"
+>     for T.
+
+This isn't semantics preserving for the Read and Input attributes. In the
+original text, they are a further level out from the other two bullets, and both
+of the other bullets apply to other subprograms, while Read and Input
+unconditionally check their result.
+
+The original bullet for Read/Input said:
+
+After a successful call on the Read or Input stream-oriented stream attribute of
+the type T, the check is performed on the object initialized by the attribute;
+
+I don't see how you can get that semantics from the above text. (I'm also not
+sure what object is getting "initialized" by either of these attributes -- for
+Read, an out parameter is being written, and for Input, there is a function
+result. Neither of these are formally "initialization". Perhaps you were trying
+to make sense of this wording??)
+
+In any case, the original semantics seems to be that an invariant check is
+performed the out parameter of Read and the function result of Input, regardless
+of where they appear. And there is no rule about "parts" in this case. While
+"parts" might be an omission (or not; it's gotten too late to continue to think
+about this), the "regardless of where they appear" is certainly intended (the
+same sort of rule applies to initialization by default, after all).
+
+The one good thing about moving this to Static Semantics is that we can justify
+the use of static determination of parts much easier when the rule in question
+is clearly static.
+
+But I can't tell how you determine what is "subject to an invariant check" for
+Read or Input, especially in the case where the default implementation is used
+(and thus there is no declaration of a subprogram to fall back on).
+
+----
+
+Gaaa!! It's 2:30 AM!! I need to go home!! Luckily, I'm done reviewing this AI.
 
 ***************************************************************

Questions? Ask the ACAA Technical Agent