CET1@phoenix.cambridge.ac.UK (Chris Thompson) (03/23/89)
In article <4799@tekgvs.LABS.TEK.COM> toma@tekgvs.LABS.TEK.COM (Tom Almy) writes > If you are really tricky, you could do something like: > temp, min, max := min, max, temp > to exchange the functions "min" and "max" anywhere they are used! In article <3510@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) replies > And, like the COBOL "ALTER" verb you're crazy if you try it. Besides, I > thought "min, max := min, max" would do the job. This actually touches on a sore point in the semantics of BCPL. Peter is wrong: all BCPL compilers I have ever come across treat the multiple assignment e1, e2, ..., en := f1, f2, ..., fn as equivalent to the sequence e1 := f1 ; e2 := f2 ; ... ; en := fn with the order of evaluation of the LHSs and RHSs that that implies. Most descriptions of the BCPL language (for example, "BCPL, the language and its compiler", by Richards & Whitby-Stevens) define the semantics of the multiple assignment in those terms. However, a lot of us would prefer that the order of evaluation should at least be undefined, even if the cause of true parallel evaluation is lost. (By the way, the case of simultaneous *declarations* is quite different: they are evaluated in parallel (more or less). This is one reason why the semantics of multiple assignments are so upsetting.) I would suggest that the appropriate code fragment is $( LET temp = min min := max ; max := temp $) to avoid any undesirable assumptions. (Of course, this applies to switching any pair of variables: I don't mean to imply that the particular example of switching two routines was an instance of good programming style!) Tom Almy adds > (And I haven't used BCPL in over 15 years now) (He still got it right, though!) I use it every day. (Well, almost.) BCPL is alive and ... (still twitching, anyway) over here. Chris Thompson Cambridge University Computing Service JANET: cet1@uk.ac.cam.phx ARPA: cet1%phx.cam.ac.uk@nss.cs.ucl.ac.uk