Re: M0036.03 Flavors and standard invalidation
On 2012-08-29 19:17:43 +0100, John Pryce wrote:
> I guess Vincent's argument trumps Michel's. A revision of a standard
> should not invalidate a previously conforming *program*, nor require
> it to have different functional behaviour. Is that right?
That's right, assuming that the program doesn't use undefined or
implementation-defined features (in which case the program can
behave differently even without a revision of the standard).
> (It might require new behaviour that can be regarded as
> non-functional, e.g. make rules for writing stuff to a log file.)
I don't understand what you mean here.
> Except for one thing. The only functional requirement my draft
> flavor document makes AFAIK, is that there shall be a decoration D
> that says "this was a common evaluation at Level 2". That is:
> "The input box X = (X_1,...,X_k) to operation phi has components
> X_i that are closed, bounded, nonempty intervals; phi is everywhere
> defined and continuous on X; and the implementation was able to
> find a closed, bounded, nonempty interval Y of the destination type,
> that contains the range of phi over X."
Well, note that even if Motion 36.3 is rejected, one could have such
a decoration, which could even be useful in the context of set-based
interval arithmetic.
> If we don't require such a decoration to exist now, but some future
> revision requires it, it seems possible that a conforming program,
> if not written with D in mind, might behave differently under the
> revised standard.
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.
Moreover I think that the standard should allow implementation-defined
decorations (this rule could be implicit, as they shouldn't affect the
behavior as specified by the standard), which could be standardized
later if they appear to be useful.
> > However if flavors are specified in the first standard and if some
> > mistake (currently not visible due to the lack of an implementation)
> > is made with the flavor specification, fixing it in the future could
> > introduce incompatible changes, and this would be bad.
>
> That is a valid point. It applies, however, to all parts of a
> standard,
That's why I think that the standard shouldn't be too complex, too
theoretic (see the past discussions about the most complex decoration
schemes, for instance).
> so the question is how far the newness of flavors makes
> them less trustworthy than the rest of the standard.
--
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)