Re: Proposed disposition of comments
On 2015-04-15 09:39:12 -0400, Michel Hack wrote:
> On Wed, 15 Apr 2015 10:50:14 +0200 Vincent wrote, replying to John:
> > On 2015-04-15 07:52:21 +0000, John Pryce wrote:
> > > The last sentence is as suggested by Vincent & Michel, instead of
> > > "... Its value is x_com."
> > > which would be more sensible.
> >
> > It should be "Its value is x_com." otherwise this would change ...
>
> Earlier Vincent had in fact suggested:
>
> | Its value is x_com, or, in a single-flavor implementation that does
> | not support "com", newDec(x).
But the "in a single-flavor implementation that [...]" part is needed
only if no other parts of the standard imply that "com" is required.
> However, what about those other places identified by Vincent that
> imply unviversal support for the "com" decoration? This means that
> the optionality offered by 8.3 is still an inconsistency!
I would say that this is a week inconsistency, but not contradiction
if one regards this optionality as void (I think that "may do X" does
not imply that there must be a possible implementation which does not
do X).
> But perhaps we should let sleeping dogs sleep, never mind their tail.
>
> One point mentioned by Vincent was 7.1 (d), but that's in a summary,
> with details given later, so its not a requirement on its own.
>
> Another was the NOTE following 8.3, which again is not normative.
But in both cases, this must not contradict the standard.
> More problematic perhaps is the last sentence of the 1st paragraph of
> the "overview" in 9.7.1:
> "The string *com* shall denote the decoration *com* in all flavors."
> (It's just an overview -- but it says "shall".)
There's also "An all-flavor literal *shall* have the value defined here
(modulo the embedding map if it is an interval literal) in all flavors."
applied to all-flavor decorated interval literals.
> This is in addition to "if decorated it has the decoration *com*" in
> the 4th paragraph (2nd on page 30), already quoted by Vincent. This
> seems to just state a fact; there is no "shall" here.
>
> What could a standards lawyer do with this situation?
Note that to make this an issue in practice, there must first be a
new flavor trying to make "com" optional. Whatever the standard says,
I don't think that this is a good idea, perhaps unless a good reason
appears, with good arguments. When (if) this occurs, it will probably
be time to revise the current standard (without any consequence on
the existing implementations on this subject) or to regard the current
text as a defect and solve the issue in a better way than what we can
do now.
--
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)