Newsgroups: | comp.compilers |
From: | sethml@sloth.ugcs.caltech.edu (Seth LaForge) |
Keywords: | C++, optimize, Scheme |
Organization: | California Institute of Technology, Pasadena, CA |
References: | 95-08-034 95-08-096 |
Date: | Wed, 16 Aug 1995 07:07:08 GMT |
Paul Eggert <eggert@twinsun.com> wrote:
>In my opinion, order-of-evaluation is the most important problem
>area in the C Standard proper. Other language standards since Algol 68
>(e.g. Ada, Fortran, PL/I, Scheme) have addressed this issue more clearly.
>Future C and C++ standards should do so as well.
I don't know about the others, but the Scheme standard (The Revised ^
4 Report on the Algorithmic Language Scheme) states very clearly in
section 4.1.3 (Procedure Calls) that, as in C, evaluation order is
undefined.
I think undefined order of evaluation makes all the sense in the
world. Clearly no one order of evaluation is best; as someone's
mentioned here, some optimizers will even change the order of
evaluation within a program. I don't think it's worth constraining
optimization for dubious gain.
Also, backward compatibility is a serious problem. If anyone starts
writing code that depends on order of evaluation, then it will not be
portable to any existing compiler.
I do very much like the idea of a compiler flag to specify evaluation
order for debugging purposes. Any gcc implementors out there?
Seth
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.