ambiguous ?

[Badger BA 64810]

In article <1989Oct21.071319.8839 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
>In article <14102 at lanl.gov> jlg at lanl.gov (Jim Giles) writes:
[...]
>
>>...  Presumably, if C
>>made argument evaluation in function calls "well-defined", you would
>>would have no qualms depending on their order either...
>
>Your presumption is incorrect.  The whole purpose of && and || is to force
>conditional evaluation, and hence evaluation order.  I have no objection
>to operators whose specific purpose is to force order, when they are
>broadly useful.  I do have considerable objection to code that depends
>on evaluation order *without* putting the reader on notice of it by
>explicitly using forcing operators.
>-- 
>A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
>megabyte of flaming.           | uunet!attcan!utzoo!henry henry at zoo.toronto.edu

I'm not sure if you're saying that a known order of evaluation (OOE) is a 
*bad* idea, or that you would rather accept an undefined order so that 
all possible compiler optimizations which may depend on the OOE would be 
legalized.

There are languages which exploit either a free OOE or a fixed OOE to good 
effect.  

Edsker Djikstra's ``guarded command language'' from ``A Discipline of
Programming'' has a non-deterministic form of iteration statement
with a syntax something like:
	DO 
	[] guard1 -> stmt1a; stmt1b;
	[] guard2 -> stmt2a; stmt2b;
	OD
where ANY one of the statement lists with TRUE guards will be executed
and then the guards re-evaluated.  The DO-OD terminates when no guards 
remain true.  Dr. Djkstra gives some examples where it is actually 
*easier* to prove the algorithm correct if a definite order of evaluation
does not need to be taken into account.  

On the other hand, in Icon, order of evaluation  of argument lists, is 
precisely defined as left-to-right.  This fact, drives the sequencing of 
the ``mutual evaluation'' of all the arguments.  Mutual evaluation may
result in multiple evaluation of the arguments by backtracking through 
the results generated by each argument until all arguments can be satisfied
simultaneously.

The design of C mostly favors a simple compiler design which is free
to evaluate arguments in any order which is convenient for the
compiler writer, rather than serving any semantic purpose at all. 
It is fair to say that this no great asset to programmers who must 
now guard against an unnoticed argument order dependency.

(IMHO) The classic C/UNIX philosophy, it's better to have something
available that *can* work and just be careful not to shoot yourself in
the foot.  Of course, this occasionally fools the unwary and is a 
source of many ``gotchas''.


    -----	-	-	-	-	-	-	-	----
Bernard A. Badger Jr.	407/984-6385          |``Get a LIFE!''  -- J.H. Conway
Harris GISD, Melbourne, FL  32902             |Buddy, can you paradigm?
Internet: bbadger%x102c at trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.