Re: a question about formatOf operations

[David Hough 754R work <754r@xxxxxxxxxxx>]

> > In my view, the principal issue is that clause 10 (expression evaluation)
> > recommends that:
> >
> > 1) languages define the "literal meaning" of arithmetic statements by
> > translating them into 754R operations
>
> In general, programming language vendors don't want that.
> Most users don't want that either.

The "literal meaning" is what you get by default, unoptimized.
Why would users not want that to be documented and implemented?
Some might not care, but how would any of them be threatened?
Most users mainly care about compile time and debuggability of unoptimized code.
Optimized code may well deviate from the "literal meaning" due to the
difference between floating-point arithmetic and real numbers.
Users ask for that by specifying how much optimization they want. 

> > according to these principles, Fortran should define the semantics of
> >       w = x + y + z
> > whether from left to right or right to left, and if the types differ,
> > where widening of operands occurs.

> > That is completely unacceptable.  Fortran is not going to do that.

That might be true - it's hard to predict what a committee might do.
But people said that 754 was wasting its time because
IBM and DEC and Cray would never adopt the specification.     This was true
for a while but not forever.

> > But Fortran should also define
> > portable directive/attributes with meanings like "allow all value-changing
> > optimizations"  or "allow re-association of unparenthesized expressions"
> > or "allow re-association of parenthesized expressions that are mathmetically
> > reassociable", and implementations should respond to those directives
> > by optimizing the computation.
>
> Not one proposal in this direction (and there have been several) have
> been even close to achieving lack of consensus against them, let alone
> achieving consensus in favour of them.

Yet there are numerous instances of compiler directives with larger or smaller
scopes being used to extend Fortran in various ways, 
not as smoothly as if they had been 
integrated into the language.    And every Fortran compiler has something like
"-O" as a compile time option with large scope, augmented by a vast set of
modifiers unique to each implementation.    It would have been better if 
something
more portable were better integrated with the language.

> Fortran doesn't standardise computer arithmetic and its properties at all.
> As far as Fortran is concerned, it is outwith the scope of the standard.
> It is not defined by the language or by the processor: it is not defined
> at all.

That's an interesting position for a language oriented toward floating-point
computation!

> But why doesn't 7.4.1 have 'formatOf nextAfter', to mention just
> one significant omission that I have had to code several times?

Please explain exactly what was missing!
But the current draft doesn't have nextAfter at all; it has nextUp and nextDown 
which, being exact, don't need a formatOf form: (cast) nextUp(operand)
will produce the result in the format of the cast with at most one rounding 
error.

>         A = B+C*D
>
> turns into:
>
>         CALL MULTIPLY(temp1, C, D)
>         CALL ADD(temp2, B, temp1)
>         CALL STORE(A, temp2)

Of course nobody wants to do that, but as you know, operator overloading for
user-defined types is still controversial with many language designers...
independent of anything 754R might say or not say.

> the concept of a "literal meaning" in IEEE 754R terms.  C's abstract
> model could be changed to meet it readily enough, though it would be
> unbelievably politically contentious, but I doubt that Fortran's or
> C++'s could.
>
> Note that changing C's abstract model would mean, inter alia, solving
> the sequence point definition problem.  Have you ANY idea of how much
> effort has gone into that with no headway, and the bitterness of the
> controversies?
>
> ... Note that I am not talking about this as a technical impossibility, so
> much as a political one.  I don't believe that any of the standards
> organisations would tackle a change of that magnitude or could handle
> it successfully.

With committees, nothing is definitely possible or definitely impossible,
but I agree from my own experience that some propositions have very low
probability of success.

> > 4) implementations refrain from performing value-changing transformations
> > and optimizations except when licensed by the programmer
>
> Impossibility the fourth.  See (1) and (4).  Inter alia, it means
> forbidding all the liberty for higher-level optimisation that Fortran
> and C allow. I can guarantee that users will not tolerate that, no
> matter what the standards say.

Most Fortran compilers don't optimize by default; users have to say something.
Yet users manage to put -O in their Makefiles when they want it and not when
they don't, so "impossibility" seems a strong word.

So there's nothing novel about that aspect of things.    Even within a local
scope, there's nothing novel about using funny comments in Fortran or
pragmas in C to control compilation.   The novelty here is asking
the language standard to better integrate the control of compilation into
the language so that control of semantics is portable too.     
This may be impossible as you say, but only because of the dynamics of
standardization committees.