kent@xanth.UUCP (04/11/87)
In article <995@wanginst.EDU> mckeeman@wanginst.EDU (William McKeeman) writes: >I am a bit frustrated by people talking past each other on this topic. The >order of evaluation rules in C are a blanket over several subproblems. [...lots of good stuff...] >Conclusion: when making a pitch for a better C definition rule, identify >which of the problems: > unrestricted optimization > overflow anomalies > roundoff anomalies > side effect anomalies >it is designed to solve. If you don't intend for your rule to have >language-wide implications, state the limited area of application. >-- >W. M. McKeeman mckeeman@WangInst >Wang Institute decvax!wanginst!mckeeman >Tyngsboro MA 01879 I agree that this is an excellent idea, and, being nothing if not opinionated, and having freely confessed my disenchantment with C in its present state in this forum previously, I will start this discussion off with four new subjects corresponding to (Mr., Mrs., Miss, Ms., Dr., (?)) McKeeman's plan, and then sit back and read the responses. I wish, for my own purposes, to promote a standard C which gives the programmer exact control over the execution order of his code. For me, this promotes an intuitive access to the code, something I find missing now. I have a lot of sympathy with a previous posting which held C up as a systems programming language, which needed the "blinding speed" of unrestrained optimization. I've done a bit of systems code myself, under somewhat worse than usual time constraints, because it was a real time graphics system, with 1/30 of a second to do everything once. However, like the bemusement Nicolas Wirth must feel at seeing his teaching toy language, Pascal, used for every variety of processing (we used it to write our OS in the same graphics system), C systems programmers must feel a sense of loss that they are now the minority users of C. C is now doing games, business data processing, mathematical processing, and who knows what else. Like the sudden demand for dynamic arrays in Pascal, there may be demand from this new, broader audience, for more disciplined behaviour from C. At least, I have seen a couple of correspondents in this who have supported some of my previous postings. ;-) C _must_ still support the needs of the systems programmers, or we suddenly lose UNIX(m) and its clones, arguably the most widely ported operating system in the world, and thus a valuable property to maintain. Without proposing the mechanism ( I helped design one "language", GKS, and one is enough), I propose that _a_ mechanism be provided in standard C to force execution of the code exactly as the programmer wrote it, to promote the "easy" verification and validation of programs written in the language. Among other purposes, this supports the creation of secure kernals for UNIX. The contrary of this mechanism would be the current unrestrained optimization methods used by today's compilers. I leave as a problem for the net the granularity of control, both in terms of scope (whole compilation unit, block, statement, or expression), and in terms of the degree to which the code must be respected (or: what optimizations are prohibited). I suggest that, along both dimensions, several stopping points, and thus several mechanisms, or one very clever one, must be provided. Comments? Kent. -- The Contradictor Member HUP (Happily Unemployed Programmers) // Also // A Back at ODU to learn how to program better (after 25 years!) \\ // Happy \// Amigan! UUCP : kent@xanth.UUCP or ...{sun,cbosgd,harvard}!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. Author grants race around long enough to see retransmission rights recursively only. a bit more of the universe?
jbuck@epimass.UUCP (Joe Buck) (04/13/87)
In article <819@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes: >C _must_ still support the needs of the systems programmers, or we suddenly >lose UNIX(m) and its clones, arguably the most widely ported operating >system in the world, and thus a valuable property to maintain. Without >proposing the mechanism ( I helped design one "language", GKS, and one is >enough), I propose that _a_ mechanism be provided in standard C to force >execution of the code exactly as the programmer wrote it, to promote the "easy" >verification and validation of programs written in the language. Among other >purposes, this supports the creation of secure kernals for UNIX. But Kent, ANSI did listen to you. Previously in C, you were right, there was no way to force an order of evaluation other than with use of parentheses. ANSI first added unary + so the compiler and atoi would match (atoi allowed a unary + and C didn't). Lots of people had the same complaint you did, so unary + was also given the property that it forces a particular order of evaluation. I find the unary + mechanism somewhat ugly, but not as much as some others find it. Why do you think it's inadequate? -- - Joe Buck {hplabs,ihnp4,sun,ames}!oliveb!epimass!jbuck seismo!epiwrl!epimass!jbuck {pesnta,tymix,apple}!epimass!jbuck