Re: Motion P1788/M0061:REvisedFlavorsText -- YES
Vincent, P1788
My apologies for taking so long to respond to this.
On 2014 Feb 28, at 14:35, Vincent Lefevre wrote:
(1)
> §7.5.3, 1st paragraph: "For each flavor-specific operation, the flavor
> shall give a rule to determine when an implementation shall provide a
> T-version." but what's the point of defining a Level 1 flavor-specific
> operation but not provide it at Level 2? In any case, I don't think
> that this sentence is useful.
My sentence is poorly written, but I think something should be said. We have one of these meta-questions:
Should the standard say a flavor SHALL, or SHOULD, say what
types one of its implementations SHALL, or SHOULD, provide
for a flavor-specific operation?
VL says "...what's the point of defining a Level 1 flavor-specific operation but not provide it at Level 2?" None, but shouldn't the flavor-designer give guidance to the implementer?
IMO the flavor SHALL state something, either a SHALL or a SHOULD, about this. Views please, if it's agreed to include something, then please offer better wording.
(2)
> §7.5.3, 3rd paragraph: in "a /special value/ of the output means a
> flavor-defined datum that either has diagnostic value, or is regarded
> as useful in practice", the part "or is regarded as useful in practice"
> doesn't seem to bring any information as it is too vague. And isn't a
> special value related to some particular operation and inputs? I mean
> that in mid(Entire) = 0, 0 is regarded as a special value, but in
> mid([-1,1]) = 0, 0 isn't a special value. The specification doesn't
> make this clear. I suggest that the notion of special value be removed;
> it can be replaced below by "flavor-defined value", and the reason for
> such a rule can be explained with an example, like the one about mid().
> The specialness of the value in this context just comes from the fact
> that it isn't defined at Level 1.
OK, I'll go with that. How about changing the para above the example to
"In the description below, sometimes a flavor-defined Level 2 value may be returned in cases where no Level 1 value exists, instead of or alongside signaling an exception."
Change "special" to "flavor-defined" below. Leave the example unchanged otherwise.
(3)
> §7.5.3, last line "(d) If Y is boolean, phi_T returns Y.": Shouldn't
> some flavor-, implementation- or language-specific behavior be allowed
> in case it is too hard to determine the boolean (i.e. the "not found"
> case)? Implementations or languages that have an "Indeterminate" or
> (equivalently) "{True,False}" value in addition to "True" and "False"
> could use it.
Good point, but hasn't this been covered by Step 2 of this algorithm? If not clear, suggest improved wording.
I've done item (2) and will wait for comments on (1,3).
John