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

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

--- ai12s/ai12-0075-1.txt	2018/01/18 08:43:00	1.8
+++ ai12s/ai12-0075-1.txt	2018/01/27 04:54:50	1.9
@@ -1286,3 +1286,671 @@
 Gaaa!! It's 2:30 AM!! I need to go home!! Luckily, I'm done reviewing this AI.
 
 ***************************************************************
+
+From: Steve Baird
+Sent: Thursday, January 18, 2018  3:37 PM
+
+> 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.
+> 
+
+Makes sense. I didn't mean to introduce two Static Semantics sections.
+
+> ----
+> 
+>>   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.)
+
+Good point. I agree that we could go either way on this question; there are
+reasonable arguments on both sides. If we do decide to allow this, then we
+should include an AARM note to make things clear.
+
+> ----
+> 
+>>   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 agree that the aspect value needs to be static.
+
+> 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.
+
+This is just a matter of presentation. We could say
+
+    The Lumpy aspect may be specified for a slimy galumph.
+or
+    The Lumpy aspect may be specified for a galumph.
+   Legality Rules
+    The Lumpy aspect shall not be specified for a non-slimy galumph.
+
+and it has no effect on the language definition. It's just a matter of what is
+clearer for human readers.
+
+If we later decide that it makes sense to allow a lumpy-but-not-slimy galumph,
+then having to modify the first version doesn't seem very hard. We'd probably
+have to add wording in that neighborhood in either case in order to give rules
+for the new construct.
+
+I think the presentation I proposed (i.e., defining the term "potentially
+static expression function") is the most readable of the alternatives that I
+considered, but we can certainly discuss other formulations.
+
+> Anyway, I suggest something more like:
+
+You get kudos in any case just for suggesting a concrete alternative.
+
+> 
+>     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)).
+
+It means that when somebody proposes a language change that allows an
+expression function as primitive operation of an interface type, then that
+person has some work to do in this area. I don't think this is ever going to
+happen (see all the grief that came from allowing null procedures as primitives
+for interface types and the "one is chosen arbitrarily" rule in 8.3).
+
+> 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.
+
+I believe my proposed wording does this, at least in effect.
+
+> 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.
+
+I don't give much weight to this because (as noted above) I don't think the
+kind of change that would demonstrate this problem is very likely.
+On the other hand, for example, I think it would be more likely that someday
+we might want to allow a static view of an expression function which is a
+completion if the completion is appropriately visible (which would need to be
+defined).
+
+> 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).
+
+I don't feel strongly about this, but I think we should decide this on the
+basis of readability and clarity, as opposed to trying to ease future possible
+changes to the language. I'm not against avoiding maintenance hazards in
+general (quite the contrary! And I also like apple pie), but in this particular
+case ... well, I've stated my opinion above.
+
+> 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.
+
+Agreed.
+
+> 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) >
+
+An object of type T cannot have a subcomponent of type T, so I believe the
+change I suggested is semantics-preserving. Can you sketch out a
+counterexample?
+
+> 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).
+
+The profile of Read or Input is well-defined in that case and so the usual
+rules are followed. Would an AARM note clarifying this help?
+
+> Gaaa!! It's 2:30 AM!! I need to go home!! Luckily, I'm done reviewing 
+> this AI.
+
+You really think you are done?
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 18, 2018  4:20 PM
+
+...
+> > 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.
+> > 
+> 
+> This is just a matter of presentation. We could say
+> 
+>     The Lumpy aspect may be specified for a slimy galumph.
+> or
+>     The Lumpy aspect may be specified for a galumph.
+>    Legality Rules
+>     The Lumpy aspect shall not be specified for a non-slimy galumph.
+> 
+> and it has no effect on the language definition. It's just a matter of 
+> what is clearer for human readers.
+
+True, but your presentation requires the introduction of more terms
+(specifically, "static expression function"). If the aspect is defined for
+all expression functions, then one simply can talk about the value of the 
+aspect and avoid defining terms. (Probably one could get rid of "potentially
+static expression function" as well, as that is only used in the Legality
+Rule; one could simply put all of the conditions into the Legality Rule and
+forget the term).
+
+All things being equal, we usually prefer the introduction of fewer terms,
+because it decreases the cognitive load on readers. I realize that things
+aren't always equal.
+
+My suggestion to eliminate the term "potentially static expression function"
+would lead to a Legality Rule that reads something like:
+
+  Aspect Static shall only be specified to have the value True if the
+  associated 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.
+
+I don't think the term is used anywhere else, and it puts the entire Legality
+Rule in one place.
+
+> If we later decide that it makes sense to allow a lumpy-but-not-slimy 
+> galumph, then having to modify the first version doesn't seem very 
+> hard. We'd probably have to add wording in that neighborhood in either 
+> case in order to give rules for the new construct.
+
+I suppose, but some of these rules are really obscure (especially if the use
+of expression functions is expanded -- will someone remember to update these
+rules??).
+ 
+> I think the presentation I proposed (i.e., defining the term 
+> "potentially static expression function") is the most readable of the 
+> alternatives that I considered, but we can certainly discuss other 
+> formulations.
+
+I think it defines a whole bunch of similar terms which are only used once (and
+not even recursively). I'd like to reduce the number of such terms.
+ 
+...
+> > 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)).
+> 
+> It means that when somebody proposes a language change that allows an 
+> expression function as primitive operation of an interface type, then 
+> that person has some work to do in this area. I don't think this is 
+> ever going to happen (see all the grief that came from allowing null 
+> procedures as primitives for interface types and the "one is chosen 
+> arbitrarily" rule in 8.3).
+
+You seem to have missed my point. If there is inheritance, there could be
+multiple "corresponding primitive functions". For instance, there could be one
+corresponding primitive function that is not an expression function and one
+that is an expression function (for the sake of discussion, assume that this
+one could have the aspect, so we don't get bogged down about the exact rules
+for the aspect). The wording doesn't say at all which one is being talked
+about; both of them are "corresponding primitive functions". But one has the
+aspect (and can inherit it) and the other does not. What happens in this case
+(especially if the one with the aspect has the value True)?
+
+There is no "THE corresponding primitive function" in that case. I suggested at
+least saying "some corresponding primitive function" if you want to ignore all
+of them but the (single) expression function. I could live with that (not
+thrilled as noted elsewhere), but what you have does NOT work if there are
+multiple inherited functions. However, a rule like that would mean that
+staticness would again be view-specific (coming through the interface would
+not be static, while coming through the concrete parent would be).
+Maybe it doesn't matter -- do you have a rule disallowing a dispatching call
+from being static?
+
+...
+> > If we reordered this clause as I suggested, that would naturally go 
+> > after 6.8(5/4).
+> 
+> I don't feel strongly about this, but I think we should decide this on 
+> the basis of readability and clarity, as opposed to trying to ease 
+> future possible changes to the language. I'm not against avoiding 
+> maintenance hazards in general (quite the contrary! And I also like 
+> apple pie), but in this particular case ... well, I've stated my 
+> opinion above.
+
+Fair enough. Maintenance was the main reason that came to mind at 2 am, but
+having slept on it, I think reducing the number of terms needed is a more
+important benefit. Also, writing this aspect more like other similar aspects
+(No_Return, Nonblocking at least) is better for consistency of the Standard.
+
+...
+> > 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).
+> > 
+> 
+> The profile of Read or Input is well-defined in that case and so the 
+> usual rules are followed. Would an AARM note clarifying this help?
+
+No. The real problem is the structure of the bullets. You have three top-level
+bullets, but they are combined as follows:
+
+   Bullet1 or (Bullet2 and Bullet3)
+
+[At least, that is how they are combined in the original text.]
+
+And that doesn't work, because you can't have different conjunctions between
+bullets of the same level.
+
+Moreover, organized as I have them above, there is nothing that says for
+bullet1 what parts of the operation are checked (that's only mentioned in
+bullet2, and that is "or"ed with bullet1).
+
+In the original wording, bullet1 is out a level from bullets 2 and 3. I
+understand why you want to avoid that, but the way you have the wording doesn't
+work.
+
+> > Gaaa!! It's 2:30 AM!! I need to go home!! Luckily, I'm done 
+> > reviewing this AI.
+> 
+> You really think you are done?
+
+Just for last night. I didn't think it would take a whole hour to write up what
+I thought was a short message (until I stumbled onto the progenitor inheritance
+and bullet ordering issues). By the time I got done, I was too asleep to care
+much more. I figured I'd have to convince you/the group of some of the changes
+going forward, but sleep came first.
+
+***************************************************************
+
+From: Steve Baird
+Sent: Friday, January 19, 2018  12:06 PM
+
+> My suggestion to eliminate the term "potentially static expression function"
+> would lead to a Legality Rule that reads something like:
+> 
+>    Aspect Static shall only be specified to have the value True if the
+>    associated 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.
+> 
+> 
+...
+> 
+> I think it defines a whole bunch of similar terms which are only used 
+> once (and not even recursively). I'd like to reduce the number of such terms.
+>   
+
+That's a more convincing argument (IMO). I like your version.
+
+> ...
+
+> You seem to have missed my point. If there is inheritance, there could 
+> be multiple "corresponding primitive functions". For instance, there 
+> could be one corresponding primitive function that is not an 
+> expression function and one that is an expression function (for the 
+> sake of discussion, assume that this one could have the aspect, so we 
+> don't get bogged down about the exact rules for the aspect). The 
+> wording doesn't say at all which one is being talked about; both of 
+> them are "corresponding primitive functions". But one has the aspect 
+> (and can inherit it) and the other does not. What happens in this case
+> (especially if the one with the aspect has the value True)?
+
+Could you provide an example? A given inherited function comes from exactly
+one primitive function of a parent/progenitor type (e.g., that's how formal
+parameter names are determined for named-notation calls to the inherited
+subprogram), so I don't see the issue.
+
+> There is no "THE corresponding primitive function" in that case. 
+
+At least one of us is confused about this point.
+
+> I suggested
+> at least saying "some corresponding primitive function" if you want to 
+> ignore all of them but the (single) expression function. I could live 
+> with that (not thrilled as noted elsewhere), but what you have does 
+> NOT work if there are multiple inherited functions. However, a rule 
+> like that would mean that staticness would again be view-specific 
+> (coming through the interface would not be static, while coming through the
+> concrete parent would be). Maybe it doesn't matter -- do you have a rule
+> disallowing a dispatching call from being static?
+
+Yes, that is a consequence of the current rules (a tagged formal parameter
+would not have a static subtype and you can't have a dispatching call without
+a tagged formal parameter).
+
+> ...
+>>> If we reordered this clause as I suggested, that would naturally go 
+>>> after 6.8(5/4).
+>>
+>> I don't feel strongly about this, but I think we should decide this 
+>> on the basis of readability and clarity, as opposed to trying to ease 
+>> future possible changes to the language. I'm not against avoiding 
+>> maintenance hazards in general (quite the contrary! And I also like 
+>> apple pie), but in this particular case ... well, I've stated my 
+>> opinion above.
+> 
+> Far enough. Maintenance was the main reason that came to mind at 2 am, 
+> but having slept on it, I think reducing the number of terms needed is 
+> a more important benefit. Also, writing this aspect more like other 
+> similar aspects (No_Return, Nonblocking at least) is better for consistency
+> of the Standard.
+
+Agreed.
+
+> ...
+>>> 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).
+>>>
+>>
+>> The profile of Read or Input is well-defined in that case and so the 
+>> usual rules are followed. Would an AARM note clarifying this help?
+> 
+> No. The real problem is the structure of the bullets. You have three 
+> top-level bullets, but they are combined as follows:
+> 
+>     Bullet1 or (Bullet2 and Bullet3)
+> 
+> [At least, that is how they are combined in the original text.]
+> 
+> And that doesn't work, because you can't have different conjunctions 
+> between bullets of the same level.
+> 
+> Moreover, organized as I have them above, there is nothing that says for
+> bullet1 what parts of the operation are checked (that's only mentioned 
+> in bullet2, and that is "or"ed with bullet1).
+> 
+> In the original wording, bullet1 is out a level from bullets 2 and 3. 
+> I understand why you want to avoid that, but the way you have the 
+> wording doesn't work.
+
+I think I finally understand the issue and I agree with you that there is a
+problem. Sometimes it takes me a while.
+
+Would it work to replace
+
+    - 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:
+
+with
+
+    - 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), or is the Read or Input stream-oriented attribute
+      of type T, and either:
+
+?
+
+The "and either" part will always be True in the case of T's Read/Input attrs,
+but the difference is that the later reference to "Each such part of type T"
+would then be well-defined in the Input/Read case.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Monday, January 22, 2018  10:49 PM
+
+> > My suggestion to eliminate the term "potentially static expression function"
+> > would lead to a Legality Rule that reads something like:
+> > 
+> >    Aspect Static shall only be specified to have the value True if the
+> >    associated 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.
+> > 
+> > 
+> ...
+> > 
+> > I think it defines a whole bunch of similar terms which are only 
+> > used once (and not even recursively). I'd like to reduce the number of such
+> > terms.
+> 
+> That's a more convincing argument (IMO). I like your version.
+
+I don't like it much, I just like it better than yours :-). It needs some
+wordsmithing, but that can be done later.
+
+> > ...
+> 
+> > You seem to have missed my point. If there is inheritance, there 
+> > could be multiple "corresponding primitive functions". For instance, 
+> > there could be one corresponding primitive function that is not an 
+> > expression function and one that is an expression function (for the 
+> > sake of discussion, assume that this one could have the aspect, so 
+> > we don't get bogged down about the exact rules for the aspect). The 
+> > wording doesn't say at all which one is being talked about; both of 
+> > them are "corresponding primitive functions". But one has the aspect 
+> > (and can inherit it) and the other does not. What happens in this 
+> > case (especially if the one with the aspect has the value True)?
+> 
+> Could you provide an example? A given inherited function comes from 
+> exactly one primitive function of a parent/progenitor type (e.g., 
+> that's how formal parameter names are determined for named-notation 
+> calls to the inherited subprogram), so I don't see the issue.
+
+Humm. You are clearly thinking of the rules 8.3(12-12.3). But those rules
+don't change the inherited subprograms (they're ALL inherited), those just
+change the ones that are *visible*. There's nothing in your wording or in
+8.3(12-12.3) that would prevent one from considering them as "corresponding
+primitive functions". Just because something is hidden doesn't mean that it
+oesn't exist! (I see that one of the AARM notes even mentions that these
+hidden items still can be inherited by future derivations.)
+
+[Aside to our newish observers: Yes, this does seem like "angels on a pinhead",
+but most of our discussions are more interesting than this. And Steve usually
+is the one who comes up with these sorts of subtle distinctions, so I'm happy
+for a bit of turnabout.]
+
+> > There is no "THE corresponding primitive function" in that case. 
+> At least one of us is confused about this point.
+
+Yes, I certainly agree with this. ;-)
+
+This rule is talking about inheritance from declared functions, and not
+talking about visibility at all. 8.3(12-12.3) therefore is irrelevant. QED.
+ 
+> > I suggested
+> > at least saying "some corresponding primitive function" if you want 
+> > to ignore all of them but the (single) expression function. I could 
+> > live with that (not thrilled as noted elsewhere), but what you have 
+> > does NOT work if there are multiple inherited functions.
+
+Note that this entire discussion boils down to changing a single "the" to
+"some". Hard to believe you're objecting to that...
+
+...
+> > However, a rule
+> > like that would mean that staticness would again be view-specific 
+> > (coming through the interface would not be static, while coming 
+> > through the concrete parent would be).
+> > Maybe it doesn't matter -- do you have a rule disallowing a 
+> > dispatching call from being static?
+> 
+> Yes, that is a consequence of the current rules (a tagged formal 
+> parameter would not have a static subtype and you can't have a 
+> dispatching call without a tagged formal parameter).
+
+I think I realized this when I reread it after sending. This would only become
+an issue if we extended staticness to private types and selected record types.
+(And we're probably not doing that, even though it would make a lot of sense
+for types like Address and Complex.)
+
+...
+ > No. The real problem is the structure of the bullets. You have three 
+> > top-level bullets, but they are combined as follows:
+> > 
+> >     Bullet1 or (Bullet2 and Bullet3)
+> > 
+> > [At least, that is how they are combined in the original text.]
+> > 
+> > And that doesn't work, because you can't have different conjunctions 
+> > between bullets of the same level.
+> > 
+> > Moreover, organized as I have them above, there is nothing that says 
+> > for bullet1 what parts of the operation are checked (that's only 
+> > mentioned in bullet2, and that is "or"ed with bullet1).
+> > 
+> > In the original wording, bullet1 is out a level from bullets 2 and 3. 
+> > I understand why you want to avoid that, but the way you have the 
+> > wording doesn't work.
+> 
+> I think I finally understand the issue and I agree with you that there 
+> is a problem. Sometimes it takes me a while.
+
+Not surprising when I was half asleep when I wrote up the original problem.
+ 
+> Would it work to replace
+> 
+>     - 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:
+> 
+> with
+> 
+>     - 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), or is the Read or Input stream-oriented attribute
+>       of type T, and either:
+> 
+> ?
+> 
+> The "and either" part will always be True in the case of T's 
+> Read/Input attrs, but the difference is that the later reference to 
+> "Each such part of type T" would then be well-defined in the 
+> Input/Read case.
+
+I think so, as it gets rid of the mixed and/or. I showed the bullets with
+parens, but of course there are no parens between bullets at the same level,
+and "A or B and C" is not understandable.
+
+I'll have to look at the entire block to be certain that it works.
+
+***************************************************************
+
+From: Steve Baird
+Sent: Tuesday, January 23, 2018  12:53 PM
+
+>>> I suggested
+>>> at least saying "some corresponding primitive function" if you want 
+>>> to ignore all of them but the (single) expression function. I could 
+>>> live with that (not thrilled as noted elsewhere), but what you have 
+>>> does NOT work if there are multiple inherited functions.
+> Note that this entire discussion boils down to changing a single "the" 
+> to "some". Hard to believe you're objecting to that...
+
+No objection now that I understand it.
+
+***************************************************************

Questions? Ask the ACAA Technical Agent