Re: Clause 10, Expression Evaluation

[Malcolm Cohen <malcolm@xxxxxxxxx>]

On Thu, 12 Jul 2007 10:13:55 +0900, David Hough 754R work <754r@xxxxxxxxxxx> 
wrote:
> I drafted a clause 10 to replace Annexes B and C to suit my tastes.
>  
> The language about reproducibility is very compact, at least as far as
> issues related to expression evaluation go, including associativity and
> anonymous intermediate destinations.  Yet it's not too hard to compare
> with the existing text.
 
I cannot compare to the existing text, since I'm not on the committee.
 
> Please don't be concerned about the subsection numbering; that can be
> figured out later if needed.  The important point now is whether I've
> expressed my ideas clearly enough to be understood.  Understood does not
> imply agreement.
 
Well, I don't know whether I don't understand or whether I just don't agree.
To the extent that I think I understand, I don't agree there is any merit.
 
> Each programming languages shall specify one or more rules for expression
> evaluation. A rule for expression evaluation specifies:
> . the order of evaluation of operations,
 
What if it doesn't?
 
The oldest and most successful numeric programming language standard does
not now, to my knowledge has not for 30 years, and to my belief never.
 
Furthermore, it is not useful.  To echo/paraphrase Nick Maclaren,
  "Why waste time debugging a program you are NOT going to run in production."
 
It's like crash-testing a VOLVO to see whether it's safe to drive a PORSCHE.
 
The utter futility and waste of time is probably
beyond my capability to express fully.
 
> . the formats of implicit intermediate results,
 
What's an "implicit intermediate result"?
There is not necessarily any such animal.
In some popular languages, the expression defines the expression,
not a set of intermediate results.
 
> . whether assignments to explicit destinations round once or twice (see 
> below),
 
Without "seeing below", seems possible/plausible.
 
> . the formats of parameters to generic and non-generic functions,
 
What's this "generic" vs "non-generic" of which you speak?
Fortran's had generic intrinsics for 30 years, and generic user functions
for 16 years, but the bullet point makes absolutely no sense whatsoever
in their regard.
 
It doesn't make sense for C either.  C doesn't have generic functions
(at least, the C99 standard doesn't have anything it calls generic functions,
though it does have "type-generic macros").
 
> . the formats of results of generic functions
 
The "format" of the result of an ordinary function is considered to be
outwith the scope of the Fortran standard.  To my mind it's inherently
outwith the scope of a language standard, since it's a "physical property"
that has nothing to do with the language as such.
 
...
> The last operation of many expressions is an assignment
 
Not in non-expression languages it's not.  Assignment is not an expression
operation in Fortran, Pascal, Ada (IIRC), ...
 
Why do I keep getting the feeling that when some people talk about
  "language neutral specification"
or
  "language independent API"
they mean "C language specification" and "C API".
Not all languages are a mere syntactic variation on C,
nor should they be.
 
...
> As a part of expression evaluation rules, languages shall specify whether
> the next to last operation is performed by rounding once to the format of
> the explicit final destination, or by rounding first to an implicit
> intermediate format and then to the explicit final destination format.
 
Languages don't do any such thing because it's none of their business
(or in many cases the concepts referenced don't exist).
 
Cheers,
--
Malcolm Cohen, Nihon Numerical Algorithms Group KK, Tokyo, Japan.