Re: Mixing reproducible and non-reproducible code
On Dec 6 2012, Vincent Lefevre wrote:
I started to respond to each point, but don't think that it would help,
so I am responding just to the fundamental confusion.
We are clearly at cross-purposes.
We are still clearly at cross-purposes. The situation is that 1788 (and,
in particular, this section) has the following properties:
a) 1788 imposes constraints on the language definition - it does
not and cannot impose constraints on implementations
b) The language definition imposes constraints on implementations
c) The implementations impose constraints on programs
In all cases, reproducibility MUST be optional, in the following sense:
a) 1788 must not require the language to have a reproducible mode,
though it may require a specific set of reproducible operations, specified
as some sort of library procedures
b) The language must not be required to require implementations to
support a reproducibility mode, even if it specifies one - if it chooses
to do so, that is OK
c) The program must not be required to use reproducibility, even if
the implementation supports it
If you want reproducibility as an option that consenting languages
can specify, fine. Only Java and a few others will adopt it.
If a language standard doesn't have anything about reproducibility,
it isn't major a problem. Implementations can still provide
reproducibility as an option.
They cannot provide it across implementations, and my point was and is
that P1788 talks about reproducibility in absolute terms.
Providing it for a single version of a single compiler on a single
platform is one thing. Beyond that, there be dragons.
Making it mandatory as an option is a sure way of getting 1788 rejected
or grossly abused by most of the important ones.
I wonder what you mean by "mandatory as an option". There should be
nothing mandatory for the implementer and for the user.
Requiring language standards to specify it as something an implementor
may choose to support. That is a complete non-no. Many language
standards will not want anything to do with it, except perhaps as a
set of library procedures for a small range of near-trivial operations
(say, up to an including the trigonometric functions).
But reproducibility can be specified as an option, and if an
implementation claims to support it (e.g. via a special mode),
then it shall not lie. That's all.
If, by "can be", you mean "may be, at the choice of the language
definition", then I agree. Otherwise, I strongly disagree.
Regards,
Nick Maclaren.