🚀 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.

But if the statements produce the same result, despite being evaluated
in a different order, then the *program* is portable.

>When dealing with a non-portable language (like C) you can work around the
>problem by avoiding those statements which are evaluated in an
>implementation-dependent way.  But if portability is important to you--and
>I believe it should be--then it is a flaw in the language definition to
>permit the evaluation of statements which are syntactically correct
>depend on the implementation.

The following is a syntactically correct statement
1 = 1.0();
which obviously is semantically incorrect. So insert '... and semantically ..'
in the above assertion. Now one could argue that a[i]=i++; is
semantically incorrect in 'portable' C, even though it takes lint to
catch it.

The programmer can determine whether a statement will be portable
or not due to side-effects. If you make a compiler which does
not fiddle with the order of evaluation, then you may be making
*all* statements portable, but your compiler will generate significantly
less efficient code for a lot of statements which were already portable.

The main point is that the bounds of portability are well defined,
( at least they will be with ANSI C), so all you have to do is avoid
the non-portable stuff.

Why would anybody write x[i]=i++; or func( --i,--i) or j = i+i++; etc?
Even if you know it will not ported and are clever enough to know what
it does on your current compiler, it is not obvious to someone reading
the code. In fact the reader will have to look at the assembler
produced, or write a test program. If you fix this by forcing order
of evaluation, we will just have a whole new set of rules to remember.
C operator hierarchy is already enough :-)

From: mwm@eris.berkeley.edu (Mike Meyer)
>	Euclid: Maybe portable, but is there more than one implementation?

We have coders for PDP-11, 68000, vax, 6809, NS16K and possibly a few more.
You can still get burned by different word sizes, but there are tools
which can and should be used if you want portability.

Sorry if this is a little muddled, but current system load makes
editing a very time-consuming chore.

-- 
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg