🚀 go-pugleaf

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