grodberg@kodak.UUCP (Jeremy Grodberg) (04/14/87)
***PRESCRIPT***
Copies of the draft proposed ANSI X3J11 standard for C (Oct. '86) are
available for $65.00 from Global Info. Docs. (800) 854-7179.
***SUMMARY***
I must confess that I have had a change of opinion since I last posted
to this group. After much interesting discussion, I no longer feel that the
current treatment of parens should be modified. The argument that swayed me
most was that there would be little way to undo the time penalty such a
modification would impose.
There remains, however, a need for the programmer to be able to specify
the order of evaluation in a number of cases. While this can currently be
achieved with the use of explicit temporaries, that method is cumbersome
and inefficient. ANSI has proposed that the unary plus operator be given
the side effect of causing early evaluation, since it needed to be added to the
operator set for other reasons, but would not have any other effect. While
these are good reasons to give this job to the unary plus, many people,
myself included, feel that the unary plus is a kludge, ugly, inappropriate,
confusing, etc.
A number of counter proposals have been offered, most centering around
compiler options. An option could be required to disable all optimzations,
thus hopefully achieving the desired result, and could be applied to parts
of the code via the new #pragma directive. This is viewed by some as overkill,
since it disables other optimizations which may be of use. This method is
also somewhat crude, in that it lacks that ability to be used in only part
of an expression, such as a macro. A second proposal made was to allow the
volatile storage class specifier to act as the unary plus was going to.
This, I believe, would be equally confusing, since the volatile keyword
currently has a specific and well defined meaning relating to its meaning in
English, which would not extend to this usage. The consensus seems to be
that there needs to be some way to specify order of evaluation, but there has
not been a consensus on the best way to do this.
***PROPOSAL***
At the risk of making C still more complicated, I propose that the operators
"(:" and ":)" be added and do for order of evaluation what "(" and ")" do for
order of precedence. Thus, the existing code (x + y) + z, would still be
optimized as the compiler saw fit, but (:x + y:) + z (rather than +(x + y) + z)
would force the complier to add the sum of x and y to z. This construction
can be used in macros to prevent compile time optimizations as well:
#define overHBarSquared(X) ((:(X) / Hbar:) / HBar)
would prevent the compiler from calculating HBar*HBar at compile time and
subsititing X / (HBar*HBar) for the define.
I believe that the paren-colon operators are much more intuitive, as they
appear as modified parens, which highlights their similar role. Also, the
very presense of two different types of parens will serve to make programmers
aware of the difference between the two. It has been noted that until the
unary plus operator was proposed, many people did not realize their parens
were not doing what they had expected. I am afraid that the unary plus will
still be viewed as having no function by future novice programmers, leading to
the same kinds of misunderstanding. It will be easier for new C programmers
to understand that there are two different types of parens, and understand
the difference. It would also be clearer to people unfamiliar with C who are
reading code: they might easily think the unary plus was a no-op, but will
seek out an explanation of the paren-colon.
This proposal satisfies me, and I think addresses a lot of the concerns
voiced in this forum. What do YOU think?
--
Jeremy Grodberg
Usenet: ...rochester!kodak!grodberg
Arpa: grodberg@kodak or kodak!grodberg@rochesterchris@mimsy.UUCP (04/17/87)
In article <800@kodak.UUCP>, grodberg@kodak.UUCP (Jeremy Grodberg) writes: > There remains, however, a need for the programmer to be able to >specify the order of evaluation in a number of cases. Agreed (by all, I hope). >While this can currently be achieved with the use of explicit >temporaries, that method is cumbersome and inefficient. ANSI has >proposed that the unary plus operator be given the side effect of >causing early evaluation, It is not a side effect: Unary plus is not listed in the set of `commutative and associative' operators, and only those may be rearranged. (This seems a minor point, but I think it is a key one in understanding *why* the dpANS uses it.) >... many people, myself included, feel that the unary plus is a >kludge, ugly, inappropriate, confusing, etc. It is certainly ugly. > ***PROPOSAL*** > At the risk of making C still more complicated, I propose that the >operators "(:" and ":)" be added and do for order of evaluation what >"(" and ")" do for order of precedence. I would much prefer expressions bracketed with `[' and `]', if anything is to be added. (No matter what is done, unary plus will still be available, for monadic operators can be neither commutative nor associative. If nothing else, it will at least be possible to write a translator that turns `[e1] op e2' into `+(e1) op e2'.) I would suggest that those who wish to see something added---whether it be [expr] or (:expr:) or whatever else---should modify a compiler *now* and try converting some numerical analysis software to this new form. *Any* positive experience will help convince X3J11 members that the change is beneficial. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu