Re: Depending on passing mechanism

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Henry Baker <hbaker@netcom.com> replied:
 ``This is another one of those cases that give standards bodies such a
   bad name -- the behavior is well-defined as 'non-deterministic', but
   non-functional.''


Anyone who thinks that non-determinisitc = non-functional has some strqange
misconceptions. In practice, for languages designed for efficiency, you
often leave some apsects of behavior non-deterministic for very good reasons.
The case at hand is a good example. To specify call by value or call by
reference for arrays can lead to highly inefficient code in some
circumstances. Similarly, over-constraining the order of evaluation (which
affects only programs with strange side effects) can significantly damange
the efficiency of generated code.

In a later note to me (perhaps posted here I don't know), Henry commented
that the amazing Java eliminates non-determinism.

This is true, but the cost is very substantial in terms of the effect on
efficiency of generated code. For example, the requirement for absolute
adherence to IEEE would create efficiency catastrophes on machines like
the Alpha and R10000, which are very nearly IEEE compliant but not quite.
I say "would" because in practice Java implementations are quite cavalier
about such details (you may remember a student who was studying fpt
portability posting a note here that summarized his experience --
Ada good, Java terrible).

Yes, if you don't care much about efficiency you can eliminate some but
not all non-determinism (if you have tasking of some time, you cannot go
all the way to eliminating ND, though certainly Ada's annex D goes pretty
far along this route, about as far as is practical).

As for non-determinism causing lack of functionality, it is certainly
true that incompetent programmers who do not understand the language
can create non-portable programs this way, but I must say that the particular
example here is not one which seems to cause difficulties in practice.