Motion P1788/M0061:REvisedFlavorsText -- YES
I vote YES on M0061. But I have some comments for §7.5.3:
§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.
§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.
§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.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)