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
chris@umcp-cs.UUCP (Chris Torek) (10/17/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. You are taking an extreme position; I will be equally extremist. In article <1455@jade.BERKELEY.EDU> mwm@eris.berkeley.edu (Mike Meyer) replies: ... >I've got bad news for you. By that definition, the ONLY portable >languages are ones that are trivially portable, with only one >implementation. Indeed. Convert the following C code to your favourite `portable' language: main() { printf("\033[H\033[J"); exit(0); } Now tell me, what does it do on all implementations? But I have not defined `implementation' properly: an `implementation' is a complete system INCLUDING a display device. *Now* what does it do? It clears my H19 screen, but it does not clear the screen of the AJ510 in the machine room. Ergo, this is not a portable program. This is a ridiculous stand. Yet I claim it is little, if any, more ridiculous than that expressed in article <483@jc3b21.UUCP>. Every program must run in a context. The context can trivially alter the results of a program. The essence of portability is the ability to prevent such alteration within many contexts. (For precisionists, the program above is indeed unportable in one sense. If its purpose is to clear the screen, it is portable only between environments that use ANSI X3.64 compatible displays. If, however, its purpose is to print the string ESC [ H ESC [ J, the program is portable between all ASCII environments. Its operation on an EBCDIC machine is less well defined.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
g-rh@cca.UUCP (Richard Harter) (10/18/86)
References: As a side issue, there are some absolutely portable languages. My favorite is IBM1401 assembler! By now the last of 1401 emulators *may* have bitten the dust, but a few years ago there were still people who made a living maintaining 1401 programs. -- Richard Harter, SMDS Inc. [Disclaimers not permitted by company policy.] For Cheryl :-)