Re: M0036.03 Flavors and standard invalidation
On 2012-09-06 11:29:13 +0100, John Pryce wrote:
> Replies to some points made by Vincent, plus an example to show
> "adding a new decoration" may indeed change a conforming program's
> behaviour.
I think that we should obviously allow us to add new decorations in
future revisions of the standard (if need be). So, we need to make
sure that the decoration system is designed in such a way that this
will not invalidate the current standard. Changing the behavior of a
conforming program is OK as long as how the program can be affected
is documented (basically, this would be an implementation-defined
behavior). Such kinds of problem can occur in every standard (not
just in standards actually, but also in software libraries / API's).
Said otherwise: don't specify too much (more than needed); think
about the future.
> On 30 Aug 2012, at 08:39, Vincent Lefevre wrote:
> > If the program doesn't use undefined or implementation-defined
^^^^^^^^^^^^^^^^^^^^^^
> > features, I don't see why. New decorations shouldn't affect the
> > interval results and shouldn't affect the existing decorations
> > either.
>
> Here's an example. It may be nonsense because of my misunderstanding
> language features, but here goes.
>
> Suppose -- like most schemes we discussed -- the decorations are in
> a linear sequence that we can think of as going from "best" to
> "worst". Let them be implemented in C as an enumerated type.
A standard should provide mechanisms to hide the implementation
(no hacks, but allow the implementation (compiler...) to optimize).
> This automatically provides some operations, e.g. given decoration
> values d1, d2 I think one can code "if d2 is the next in the
> sequence after d1, do XX" as
> if (d2 == d1++) {
> XX
> }
This is bad code. The standard could provide a function nextDecoration
(if it appears to be useful) and document that a future revision may
insert new decorations (and even allow an implementation to insert its
own decorations as an extension).
> Now, suppose the standard is revised and the hypothetical D is
> inserted as a new decoration in the sequence. If at run time, d1 and
> d2 are such that the above test used to be true, but D is in between
> them, then in the new standard the test is false.
If the user really wants to select the next decoration, he can use the
nextDecoration function, and his program will behave as documented, in
an implementation-defined way. If the user wants to stick with fixed
decorations, he can also do so, avoiding nextDecoration (or using a
loop and tests with it...).
> One might say that such code is bad programming style, but to
> someone who thinks "decorations have always been in exactly this
> sequence" it will look innocuous.
The user mustn't assume things that are not specified by the standard.
Even without a revision, implementations may vary. And even with the
IEEE 754 standard, which appears to specify most behaviors, there may
be differences (for instance, don't try to recognize a qNaN from its
memory representation in portable programs, because of the payload).
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)