Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ll-xn!adelie!mirror!xanth!kent From: kent@xanth.UUCP Newsgroups: comp.lang.c Subject: Re: C and Floating Point Message-ID: <790@xanth.UUCP> Date: Mon, 6-Apr-87 23:42:33 EST Article-I.D.: xanth.790 Posted: Mon Apr 6 23:42:33 1987 Date-Received: Fri, 10-Apr-87 00:38:10 EST References: <15958@sun.uucp> <5716@brl-smoke.ARPA> <14680@cca.CCA.COM> Reply-To: kent@xanth.UUCP (Kent Paul Dolan) Organization: Old Dominion University, Norfolk Va. Lines: 69 Keywords: C Fortran Floating Point Summary: another reason to honor parenthesis I may have started this part of this discussion, and it leaves me a bit in awe to be caught between representatives of X3J11, and the IEEE Floating Point Standards committee. Nevertheless, like Mr. Heinlein, I will fear no evil. (I did my stint for 4 years on X3H3, so there!) As promised in the summary, I would like to propose another (to me, excellent) reason to modify the C standard to require that compilers honor the order of expression which the programmer indicates by parentheses, programmer productivity. I'm not really (despite 25 years experience with them) that comfortable with floating point numbers, so leave that out of the discussion for now. In FORTRAN, since that seems to be the counterexample language used in these discussions, if I write an expression, and parenthesize it, I have only one possible evaluation order to debug; that is the one I have written. If I write the equivalent expression in C, I have to consider (if I'm working in a _really_ critical application, model and validate), _every_possible_ order of evaluation. Guess which takes longer. ;-) I'm sorry to be talking to a crowd of compiler writers, to whom wringing every last excess cycle out of a piece of generated code is both a matter of pride and honor, the usual way your work is evaluated, and the normal expectation of your employers, in such a tone, but it is necessary. Within reason, the speed of compiled code is a _very_minor_ cost factor in the code's life cycle cost, compared to the people costs of creating the code. We who use your compilers would create our product cheaper and better if you who design the languages would spend more time worrying about readability, writeability, intuitiveness, and maintainability, and less time worrying about the efficiency of execution of the language. It is not a _minor_ matter when a piece of code doesn't execute the way it reads, and it is not a _minor_ matter when someting like the proposed unary plus override on parenthesis evaluation order is added to a language. It is a utility destroying set of blunders by the language designers. I speak as a user of languages. In a checkered career, I have learned, and used to create working code, more thatn 40 languages (I lost track there in about 1977). I have lived with such wonders in write only code as APL, IBM 360 Assembler, PL/1 (yes, before '1' became 'I'), and LISP. C is still the single language with which I cannot become comfortable, and it is not just senility, as I have learned several languages since C. I write code in C, it works, and I still get bitten by unexpected results of straightforward looking computations _every_time_. I hate it. Please, when you make language design decisions, think of the poor boob who has to use the resulting mess, and take the time to do it right, not just patch the patches. It is no argument to say that conforming compilers will have to be revised if parenthesization order must be respected. The ANSI standard doesn't exist yet, it is at best a dpANS, until it is voted into acceptance, so there are _no_ conforming compilers. Every compiler maker will have to go back and do massive rewrites to make existing production compilers into conforming compilers. What is true, is that respecting parentheses will break no code not already buggy. Think it over. I'll try to keep out of the XfXiXgXhXtX discussion for a few weeks. -- The Contradictor Member HUP (Happily Unemployed Programmers) Back at ODU to learn how to program better (after 25 years!) UUCP : kent@xanth.UUCP or ...seismo!decuac!edison!xanth!kent CSNET : kent@odu.csnet ARPA : kent@xanth.cs.odu.edu Voice : (804) 587-7760 USnail: P.O. Box 1559, Norfolk, Va 23501-1559 Copyright 1987 Kent Paul Dolan. How about if we keep the human All Rights Reserved. race around long enough to see Recursive retransmission rights only. a bit more of the universe?