mwm@eris.berkeley.edu (Mike Meyer) (10/16/86)
In article <483@jc3b21.UUCP> fgd3@jc3b21.UUCP writes: > Your examples support my point: a _portable_ language is one which >runs identically on all implementations. A language which permits the code >generated by its statements to be implementation-dependent is not portable. Your definition is ambiguous. Given the context (expression sequencing in C), I assume you mean "... is one where all programs run identically on all implementations." If you don't mean "all" programs, then obviously the language permits code to be generated which is implemtation-dependent. Of course, this implies that the two implementations accept the same language. I've got bad news for you. By that definition, the ONLY portable languages are ones that are trivially portable, with only one implementation. Let's look at some examples: FORTRAN: Even WATFIV and IBM FORTRAN G are different, since they evaluate expressions in different order. C: We've already seen several counter-examples. FORTH/LISP/BASIC/Pascal: Multiple standards for these languages, so I won't even bother. ALGOL: No I/O defined, so every implementation has a different set. COBOL: Similar to ALGOL, except only for "terminal" I/O. PL/I: IBM's two compilers accept different languages! Euclid: Maybe portable, but is there more than one implementation? To make matters worse, if a language supports floating point numbers, I can give you code that will behave radically differently on a 360-oid machine than on a VAX, even with near-identical implementations (you see, (x * 2) / 2 is not always x on a 360-oid architechture!). From looking at the above, I'd say that C, with a small set of vague standards (K&R and H&S), and a "real" standard (ANSI) in the works, is in pretty good shape. Even better, C has a DEMONSTRATED portability nearly as good as FORTRAN. Of course, the constraints on portable code in C are worse than they are in FORTRAN, but you've got a sharper tool to work with. <mike
jason@hpcnoe.UUCP (Jason Zions) (10/16/86)
dik@mcvax.uucp (Dik T. Winter) writes: > And so should it. Once I required the expression (A - B) - C evaluated > exactly that way. It didn't do so. However, after removing the > parenthesis it was evaluated the way I wanted. Counterintuitive? Not counterintuitive - BROKEN. Although C may rearrange the order of evaluation with respect to + * & ^ and |, it may not do so w.r.t. operators which aren't associative and commutative. Rearranging (A - B) - C is just plain wrong. References: H&S Section 7.11, page 190 K&R Section 2.12, page 49 Note that both references state that reordering is permitted only for the associative and commutative operators; they do not mention the names of the operators for which reordering is forbidden. -- This is not an official statement of Hewlett-Packard Corp., and does not necessarily reflect the views of HP. It is provided completely without warranty of any kind. Lawyers take 3d10 damage and roll a saving throw vs. ego attack. Jason Zions Hewlett-Packard Colorado Networks Division 3404 E. Harmony Road Mail Stop 102 Ft. Collins, CO 80525 {ihnp4,seismo,hplabs,gatech}!hpfcdc!hpcnoe!jason