Re: Include language bindings? Re: Draft Standard Text, V02.1
> Date: Tue, 16 Mar 2010 13:55:21 +0100
> From: Marco Nehmeier <nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> To: Rudnei Cunha <rudnei.cunha@xxxxxxxxx>
> CC: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Include language bindings? Re: Draft Standard Text, V02.1
>
> I think that it's not enough to specify the operation/function by its
> own. The big problem with different languages is the different compiler
> optimization. Hence, we have to take care about a similar evaluation of
> interval expressions (see Jürgens comment "An expression shall be
> executed as it is written...").
>
> Best regards,
>
> Marco
>
Yes, our specification of how an interval expression
is to be interpreted must go beyond a mere statement
of how unary & binary operations are to be interpreted.
We must specify the whole expression. Even the
interactions between expressions (across assignments &
even loop iterations).
In particular, we must specify how associative expressions
are to be interpreted.
But, here too, the various languages present us with a
problem in formulating the specification. Some languages
state that one associates to the left. Some say to the
right. And some don't specify it at all, leaving it up
to the compiler to decide. Often in ways opaque to the
user. And then there are languages for which the issue
is moot. Scheme specifies the associativity in the
expression & Cobol (oddly enough) doesn't have the problem
due to the simplicity of its expressions.
Now, reassociating an expression will not invalidate the
containment of an interval, so correctness of the
expression itself in not at issue.
But reassociating an expression can radically alter the
width of an interval or the accuracy with which its
endpoints are rendered. Thus, an interval algorithm
might converge one way but not the other which would
invalidate the algorithm itself as a reproducible proof
of some result.
There are many more issues.
As someone has already pointed out, much of this was
discussed in the "stds-1788-er" subgroup some time back.
Some of those discussions are obsolete in light of recent
motions. Some should be revisited.
Yours,
Dan