🚀 go-pugleaf

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