 |
 |
Keith Bierman ADT/QED <[log in to unmask]> wrote: ... >As for the specific issue which sparked this incarnation of very old >controversy, I think those that have expressed a desire for a new form >of parens would do better to work on the general problem of allowing >more user control over the optimization semantics. The parens level >really is far too small in scope, and consumes irreplaceable character >set binding ;> Well, in an ideal world, optimization wouldn't have semantics. It should be a purely pragmatic issue. You should no more care (semantically) how optimization was done than you care whether the multiply is an iterated shift-add loop or a staged/parallel operation. Unfortunately(?), the standard itself introduced the possibility of semantically significant transformations by allowing mathematically equivalent operations to be done - in spite of the fact that computational arithmetic isn't mathematical. Vendors (and others) have pushed the envelope whenever possible to do similar transformations at coarser levels (multiline, constant folding, etc.). My own bias is that the only transformations that should be allowed are either those which entirely preserve the semantics of the original program or those explicitly permitted by the standard (mathematically equivalent transformations within a single expression that don't invade the integrity of parenthesis). This is because I really would like to move toward that ideal world where optimization was entirely a pragmatic issue. -- J. Giles %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%